[PATCH 1/2] Input: xpad - Minor coding style errors fixed.
From: "Guillermo A. Amaral"
Fixed a few minor coding style issues in xpad driver.
Signed-off-by: "Guillermo A. Amaral B."
---
drivers/input/joystick/xpad.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 83811e4..3d8f39b 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -235,7 +235,7 @@ static const signed short xpad_abs_triggers[] = {
{ XPAD_XBOX360_VENDOR_PROTOCOL(vend,1) }, \
{ XPAD_XBOX360_VENDOR_PROTOCOL(vend,129) }
-static struct usb_device_id xpad_table [] = {
+static struct usb_device_id xpad_table[] = {
{ USB_INTERFACE_INFO('X', 'B', 0) },/* X-Box USB-IF not approved
class */
XPAD_XBOX360_VENDOR(0x045e),/* Microsoft X-Box 360
controllers */
XPAD_XBOX360_VENDOR(0x046d),/* Logitech X-Box 360 style
controllers */
@@ -251,7 +251,7 @@ static struct usb_device_id xpad_table [] = {
{ }
};
-MODULE_DEVICE_TABLE (usb, xpad_table);
+MODULE_DEVICE_TABLE(usb, xpad_table);
struct usb_xpad {
struct input_dev *dev; /* input device interface */
@@ -783,7 +783,7 @@ static int xpad_open(struct input_dev *dev)
struct usb_xpad *xpad = input_get_drvdata(dev);
/* URB was submitted in probe */
- if(xpad->xtype == XTYPE_XBOX360W)
+ if (xpad->xtype == XTYPE_XBOX360W)
return 0;
xpad->irq_in->dev = xpad->udev;
--
1.7.8.6
--
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 GIT PULL] scheduler fix for autogroups
On Sat, 2012-12-01 at 14:03 -0800, Linus Torvalds wrote: > On Sat, Dec 1, 2012 at 1:44 PM, Ingo Molnar wrote: > > > > You are not missing anything. That flag is my fault not Mike's: > > I booted the initial version of that patch but was unsure > > whether autogroups was enabled - it's a pretty transparent > > feature. So I figured that having that flag (but readonly) would > > give us this information definitely. > > So what's the advantage of it being read-only at all? > > Since the flag is clearly *used*, make it read-write, and then all my > objections go away (except for a slight worry that the dropping of > /proc//autogroup_nice or whatever it is could break some odd > system app, but I don't worry *too* much about that). > > Disabling autogroup is clearly something people might want, since the > code tests for it. So removing the flag entirely seems wrong too. But > if it exists, it should be writable. No? No, because turning autogroup off at runtime is what now makes boom. With Peter's race fix in place, lazy movement (was noop on UP) is gone, mandating that you either walk the box, moving all tasks when you flick the switch, or you remove the ability to flick the switch other than 'off' at boot time. You didn't like the original instant on/off switch, and I didn't like the thought of making autogroup bigger to fix the explosion either, so went for rip the switch and problematic /proc stuff that really should have never existed in the first place out option. -Mike -- 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] EXTCON: Get and set cable properties
Hi Myungjoo/Chanwoo/Aneesh/Anton,
Could you please review this. This is a follow up patch for "PATCH] extcon :
callback function to read cable property"
-jtc
> Subject: [PATCH] EXTCON: Get and set cable properties
>
> Existing EXTCON implementation doesn't give a mechanim to read the cable
> properties and extra states a cable needs to support. There are scenarios
> where a cable can have more than two
> states(CONNECT/DISCONNECT/SUSPEND/RESUME etc) and can have some
> properties associated with cables(mA)
>
> This patch introduces interface to get and set cable properties from EXTCON
> framework. The cable property can be set either by the extcon cable
> provider or by other subsystems who know the cable properties using eth
> API extcon_cable_set_data()
>
> When the consumer gets a notification from the extcon, it can use the
> extcon_cable_get_data() to get the cable properties irrespective of who
> provides the cable data.
>
> This gives a single interface for setting and getting the cable properties.
>
> Signed-off-by: Jenny TC
> ---
> drivers/extcon/extcon-class.c | 30 ++
> include/linux/extcon.h| 39
> +++
> 2 files changed, 69 insertions(+)
>
> diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
> index d398821..304f343 100644
> --- a/drivers/extcon/extcon-class.c
> +++ b/drivers/extcon/extcon-class.c
> @@ -545,6 +545,36 @@ int extcon_unregister_notifier(struct extcon_dev
> *edev, } EXPORT_SYMBOL_GPL(extcon_unregister_notifier);
>
> +/**
> + * extcon_cable_set_data() - Set the data structure for a cable
> + * @edev:the extcon device
> + * @cable_index: the cable index of the correspondant
> + * @type:type of the data structure
> + * @data:
> + */
> +void extcon_cable_set_data(struct extcon_dev *edev, int cable_index,
> +enum extcon_cable_name type,
> +union extcon_cable_data data)
> +{
> + edev->cables[cable_index].type = type;
> + edev->cables[cable_index].data = data; }
> +
> +/**
> + * extcon_cable_get_data() - Get the data structure for a cable
> + * @edev:the extcon device
> + * @cable_index: the cable index of the correspondant
> + * @type:type of the data structure
> + * @data:the corresponding data structure (e.g., regulator)
> + */
> +void extcon_cable_get_data(struct extcon_dev *edev, int cable_index,
> +enum extcon_cable_name *type,
> +union extcon_cable_data *data)
> +{
> + *type = edev->cables[cable_index].type;
> + *data = edev->cables[cable_index].data; }
> +
> static struct device_attribute extcon_attrs[] = {
> __ATTR(state, S_IRUGO | S_IWUSR, state_show, state_store),
> __ATTR_RO(name),
> diff --git a/include/linux/extcon.h b/include/linux/extcon.h index
> 2c26c14..4556cc5 100644
> --- a/include/linux/extcon.h
> +++ b/include/linux/extcon.h
> @@ -135,6 +135,19 @@ struct extcon_dev {
> struct device_attribute *d_attrs_muex; };
>
> +/* FIXME: Is this the right place for this structure definition?
> + * Do we need to move it to power_supply.h?
> + */
> +struct extcon_chrgr_cable_props {
> + unsigned long state;
> + int mA;
> +};
> +
> +union extcon_cable_data {
> + struct extcon_chrgr_cable_props chrgr_cbl_props;
> + /* Please add accordingly*/
> +};
> +
> /**
> * struct extcon_cable - An internal data for each cable of extcon
> device.
> * @edev The extcon device
> @@ -143,6 +156,8 @@ struct extcon_dev {
> * @attr_name"name" sysfs entry
> * @attr_state "state" sysfs entry
> * @attrsArray pointing to attr_name and attr_state for attr_g
> + * @type:The type of @data.
> + * @data:The data structure representing the status and states of this
> cable.
> */
> struct extcon_cable {
> struct extcon_dev *edev;
> @@ -153,6 +168,11 @@ struct extcon_cable {
> struct device_attribute attr_state;
>
> struct attribute *attrs[3]; /* to be fed to attr_g.attrs */
> +
> + union extcon_cable_data data;
> +
> + /* extcon cable type */
> + enum extcon_cable_name type;
> };
>
> /**
> @@ -183,6 +203,17 @@ extern void extcon_dev_unregister(struct
> extcon_dev *edev); extern struct extcon_dev
> *extcon_get_extcon_dev(const char *extcon_name);
>
> /*
> + * Following APIs are for managing the status and states of each cable.
> + * For example, if a cable is represented as a regulator, then the
> +cable
> + * may have struct regulator as its data.
> + */
> +extern void extcon_cable_set_data(struct extcon_dev *edev, int
> cable_index,
> + enum extcon_cable_name type,
> + union extcon_cable_data data);
> +extern void extcon_cable_get_data(struct extcon_dev *edev, int
> cable_index,
> + enum extcon_cable_name *type,
> + union extcon_cable_data *data);
> +/*
>
[PATCH 2/2] Input: xpad - Added new XBOX new VID/PID combinations.
From: "Guillermo A. Amaral"
Added popular VP combinations for MadCatz, PDP and PowerA (new).
Removed Pelican 'TSZ' Wired Xbox 360 Controller since it's clashing with Edge
wireless Controller and I failed to confirm the PID.
Signed-off-by: "Guillermo A. Amaral B."
---
drivers/input/joystick/xpad.c | 27 ++-
1 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 3d8f39b..d6cbfe9 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -118,11 +118,12 @@ static const struct xpad_device {
u8 xtype;
} xpad_device[] = {
{ 0x045e, 0x0202, "Microsoft X-Box pad v1 (US)", 0, XTYPE_XBOX },
- { 0x045e, 0x0289, "Microsoft X-Box pad v2 (US)", 0, XTYPE_XBOX },
{ 0x045e, 0x0285, "Microsoft X-Box pad (Japan)", 0, XTYPE_XBOX },
{ 0x045e, 0x0287, "Microsoft Xbox Controller S", 0, XTYPE_XBOX },
+ { 0x045e, 0x0289, "Microsoft X-Box pad v2 (US)", 0, XTYPE_XBOX },
+ { 0x045e, 0x028e, "Microsoft X-Box 360 pad", 0, XTYPE_XBOX360 },
+ { 0x045e, 0x0291, "Xbox 360 Wireless Receiver (XBOX)",
MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360W },
{ 0x045e, 0x0719, "Xbox 360 Wireless Receiver", MAP_DPAD_TO_BUTTONS,
XTYPE_XBOX360W },
- { 0x0c12, 0x8809, "RedOctane Xbox Dance Pad", DANCEPAD_MAP_CONFIG,
XTYPE_XBOX },
{ 0x044f, 0x0f07, "Thrustmaster, Inc. Controller", 0, XTYPE_XBOX },
{ 0x046d, 0xc242, "Logitech Chillstream Controller", 0, XTYPE_XBOX360 },
{ 0x046d, 0xca84, "Logitech Xbox Cordless Controller", 0, XTYPE_XBOX },
@@ -136,9 +137,12 @@ static const struct xpad_device {
{ 0x0738, 0x4540, "Mad Catz Beat Pad", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX
},
{ 0x0738, 0x4556, "Mad Catz Lynx Wireless Controller", 0, XTYPE_XBOX },
{ 0x0738, 0x4716, "Mad Catz Wired Xbox 360 Controller", 0,
XTYPE_XBOX360 },
+ { 0x0738, 0x4728, "Mad Catz Street Fighter IV FightPad", XTYPE_XBOX360
},
{ 0x0738, 0x4738, "Mad Catz Wired Xbox 360 Controller (SFIV)",
MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
{ 0x0738, 0x6040, "Mad Catz Beat Pad Pro", MAP_DPAD_TO_BUTTONS,
XTYPE_XBOX },
+ { 0x0738, 0xbeef, "Mad Catz JOYTECH NEO SE Advanced GamePad",
XTYPE_XBOX360 },
{ 0x0c12, 0x8802, "Zeroplus Xbox Controller", 0, XTYPE_XBOX },
+ { 0x0c12, 0x8809, "RedOctane Xbox Dance Pad", DANCEPAD_MAP_CONFIG,
XTYPE_XBOX },
{ 0x0c12, 0x880a, "Pelican Eclipse PL-2023", 0, XTYPE_XBOX },
{ 0x0c12, 0x8810, "Zeroplus Xbox Controller", 0, XTYPE_XBOX },
{ 0x0c12, 0x9902, "HAMA VibraX - *FAULTY HARDWARE*", 0, XTYPE_XBOX },
@@ -148,24 +152,28 @@ static const struct xpad_device {
{ 0x0e6f, 0x0003, "Logic3 Freebird wireless Controller", 0, XTYPE_XBOX
},
{ 0x0e6f, 0x0005, "Eclipse wireless Controller", 0, XTYPE_XBOX },
{ 0x0e6f, 0x0006, "Edge wireless Controller", 0, XTYPE_XBOX },
- { 0x0e6f, 0x0006, "Pelican 'TSZ' Wired Xbox 360 Controller", 0,
XTYPE_XBOX360 },
+ { 0x0e6f, 0x0105, "HSM3 Xbox360 dancepad", MAP_DPAD_TO_BUTTONS,
XTYPE_XBOX360 },
{ 0x0e6f, 0x0201, "Pelican PL-3601 'TSZ' Wired Xbox 360 Controller", 0,
XTYPE_XBOX360 },
+ { 0x0e6f, 0x0213, "Afterglow Gamepad for Xbox 360", 0, XTYPE_XBOX360 },
{ 0x0e8f, 0x0201, "SmartJoy Frag Xpad/PS2 adaptor", 0, XTYPE_XBOX },
+ { 0x0f0d, 0x000d, "Hori Fighting Stick EX2", MAP_TRIGGERS_TO_BUTTONS,
XTYPE_XBOX360 },
+ { 0x0f0d, 0x0016, "Hori Real Arcade Pro.EX", MAP_TRIGGERS_TO_BUTTONS,
XTYPE_XBOX360 },
{ 0x0f30, 0x0202, "Joytech Advanced Controller", 0, XTYPE_XBOX },
{ 0x0f30, 0x, "BigBen XBMiniPad Controller", 0, XTYPE_XBOX },
{ 0x102c, 0xff0c, "Joytech Wireless Advanced Controller", 0, XTYPE_XBOX
},
- { 0x12ab, 0x8809, "Xbox DDR dancepad", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX
},
{ 0x12ab, 0x0004, "Honey Bee Xbox360 dancepad", MAP_DPAD_TO_BUTTONS,
XTYPE_XBOX360 },
- { 0x0e6f, 0x0105, "HSM3 Xbox360 dancepad", MAP_DPAD_TO_BUTTONS,
XTYPE_XBOX360 },
+ { 0x12ab, 0x8809, "Xbox DDR dancepad", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX
},
{ 0x1430, 0x4748, "RedOctane Guitar Hero X-plorer", 0, XTYPE_XBOX360 },
{ 0x1430, 0x, "TX6500+ Dance Pad (first generation)",
MAP_DPAD_TO_BUTTONS, XTYPE_XBOX },
{ 0x146b, 0x0601, "BigBen Interactive XBOX 360 Controller", 0,
XTYPE_XBOX360 },
- { 0x045e, 0x028e, "Microsoft X-Box 360 pad", 0, XTYPE_XBOX360 },
+ { 0x1689, 0xfd00, "Razer Onza Tournament Edition", MAP_DPAD_TO_BUTTONS,
XTYPE_XBOX360 },
{ 0x1bad, 0x0002, "Harmonix Rock Band Guitar", 0, XTYPE_XBOX360 },
{ 0x1bad, 0x0003, "Harmonix Rock Band Drumkit", MAP_DPAD_TO_BUTTONS,
XTYPE_XBOX360 },
- { 0x0f0d, 0x0016, "Hori Real Arcade Pro.EX", MAP_TRIGGERS_TO_BUTTONS,
XTYPE_XBOX360 },
- { 0x0f0d, 0x000d, "Hori Fighting Stick EX2", MAP_TRIGGERS_TO_BUTTONS,
XTYPE_XBOX360 },
- {
[PATCH 1/2] Input: xpad - Minor coding style errors fixed.
From: "Guillermo A. Amaral"
Fixed a few minor coding style issues in xpad driver.
Signed-off-by: "Guillermo A. Amaral B."
---
drivers/input/joystick/xpad.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 83811e4..3d8f39b 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -235,7 +235,7 @@ static const signed short xpad_abs_triggers[] = {
{ XPAD_XBOX360_VENDOR_PROTOCOL(vend,1) }, \
{ XPAD_XBOX360_VENDOR_PROTOCOL(vend,129) }
-static struct usb_device_id xpad_table [] = {
+static struct usb_device_id xpad_table[] = {
{ USB_INTERFACE_INFO('X', 'B', 0) },/* X-Box USB-IF not approved
class */
XPAD_XBOX360_VENDOR(0x045e),/* Microsoft X-Box 360
controllers */
XPAD_XBOX360_VENDOR(0x046d),/* Logitech X-Box 360 style
controllers */
@@ -251,7 +251,7 @@ static struct usb_device_id xpad_table [] = {
{ }
};
-MODULE_DEVICE_TABLE (usb, xpad_table);
+MODULE_DEVICE_TABLE(usb, xpad_table);
struct usb_xpad {
struct input_dev *dev; /* input device interface */
@@ -783,7 +783,7 @@ static int xpad_open(struct input_dev *dev)
struct usb_xpad *xpad = input_get_drvdata(dev);
/* URB was submitted in probe */
- if(xpad->xtype == XTYPE_XBOX360W)
+ if (xpad->xtype == XTYPE_XBOX360W)
return 0;
xpad->irq_in->dev = xpad->udev;
--
1.7.8.6
--
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] sp5100_tco: Add SB8x0 chipset support
The current sp5100_tco driver only supports SP5100/SB7x0 chipset, doesn't support SB8x0 chipset, because current sp5100_tco driver doesn't know that the offset address for watchdog timer was changed from SB8x0 chipset. The offset address of SP5100 and SB7x0 chipsets are as follows, quote from the AMD SB700/710/750 Register Reference Guide (Page 164) and the AMD SP5100 Register Reference Guide (Page 166). WatchDogTimerControl 69h WatchDogTimerBase0 6Ch WatchDogTimerBase1 6Dh WatchDogTimerBase2 6Eh WatchDogTimerBase3 6Fh In contrast, the offset address of SB8x0 chipset is as follows, quote from AMD SB800-Series Southbridges Register Reference Guide (Page 147). WatchDogTimerEn 48h WatchDogTimerConfig 4Ch So, In the case of SB8x0 chipset, sp5100_tco reads meaningless MMIO address (for example, 0xbafe00) from wrong offset address, and the following message is logged. SP5100 TCO timer: mmio address 0xbafe00 already in use With this patch, sp5100_tco driver supports SB8x0 chipset, and can avoid iomem resource conflict. The processing of this patch is as follows. Step 1) Attempt to get the watchdog base address from indirect I/O (0xCD6 and 0xCD7). - Go to the step 7 if obtained address hasn't conflicted with other resource. But, currently, the address (0xfec000f0) conflicts with the IOAPIC MMIO address, and the following message is logged. SP5100 TCO timer: mmio address 0xfec000f0 already in use 0xfec000f0 is recommended by AMD BIOS Developer's Guide. So, go to the next step. Step 2) Attempt to get the SBResource_MMIO base address from AcpiMmioEN (for SB8x0, PM_Reg:24h) or SBResource_MMIO (SP5100/SB7x0, PCI_Reg:9Ch) register. - Go to the step 7 if these register has enabled by BIOS, and obtained address hasn't conflicted with other resource. - If above condition isn't true, go to the next step. Step 3) Attempt to get the free MMIO address from allocate_resource(). - Go to the step 7 if these register has enabled by BIOS, and obtained address hasn't conflicted with other resource. - Driver initialization has failed if obtained address has conflicted with other resource, and no 'force_addr' parameter is specified. Step 4) Use the specified address If 'force_addr' parameter is specified. - allocate_resource() function may fail, when the PCI bridge device occupies iomem resource from 0xf000 to 0x. To handle such a case, I added 'force_addr' parameter to sp5100_tco driver. With 'force_addr' parameter, sp5100_tco driver directly can assign MMIO address for watchdog timer from free iomem region. Note that It's dangerous to specify wrong address in the 'force_addr' parameter. Example of force_addr parameter use # cat /proc/iomem ...snip... fec0-fec003ff : IOAPIC 0 <--- free MMIO region fec1-fec1001f : pnp 00:0b fec2-fec203ff : IOAPIC 1 ...snip... # cat /etc/modprobe.d/sp5100_tco.conf options sp5100_tco force_addr=0xfec00800 # modprobe sp5100_tco # cat /proc/iomem ...snip... fec0-fec003ff : IOAPIC 0 fec00800-fec00807 : SP5100 TCO <--- watchdog timer MMIO address fec1-fec1001f : pnp 00:0b fec2-fec203ff : IOAPIC 1 ...snip... # - Driver initialization has failed if specified address has conflicted with other resource. Step 5) Disable the watchdog timer - To rewrite the watchdog timer register of the chipset, absolutely guarantee that the watchdog timer is disabled. Step 6) Re-program the watchdog timer MMIO address to chipset. - Re-program the obtained MMIO address in Step 3 or Step 4 to chipset via indirect I/O (0xCD6 and 0xCD7). Step 7) Enable and setup the watchdog timer This patch has worked fine on my test environment (ASUS M4A89GTD-PRO/USB3 and DL165G7). therefore I believe that it's no problem to re-program the MMIO address for watchdog timer to chipset during disabled watchdog. However, I'm not sure about it, because I don't know much about chipset programming. So, any comments will be welcome. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43176 Tested-by: Arkadiusz Miskiewicz Tested-by: Paul Menzel Signed-off-by: Takahisa Tanaka --- v2 -> v3 - Leave a space before parentheses. - Restore the commit log v2 to v1. - Add Paul's -by line. v1 -> v2 -Fix typo in module description and source code. -Fix a bug that can't correctly determine the watchdog fired. -Improve syslog messages. -Truncate the commit log, because previous commit log is too long. --- drivers/watchdog/sp5100_tco.c | 321 +++--- drivers/watchdog/sp5100_tco.h | 46 -- 2 files changed, 306 insertions(+), 61 deletions(-) diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c index
[PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()
In order to avoid constantly allocating and deallocating there is a fixed
buffer which spi_write_then_read() uses for transfers, with an early error
check to ensure that the transfer fits within the buffer. This limits the
size of transfers to this size, currently max(32, SMP_CACHE_BYTES).
Since we can dynamically allocate and in fact already have a fallback
to do so when there is contention for the fixed buffer remove this
restriction and instead dynamically allocate a suitably sized buffer if
the transfer won't fit.
Signed-off-by: Mark Brown
---
drivers/spi/spi.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index c4f7d71..224b7bc 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1646,12 +1646,18 @@ int spi_write_then_read(struct spi_device *spi,
struct spi_transfer x[2];
u8 *local_buf;
- /* Use preallocated DMA-safe buffer. We can't avoid copying here,
-* (as a pure convenience thing), but we can keep heap costs
-* out of the hot path ...
+ /* Use preallocated DMA-safe buffer if we can. We can't avoid
+* copying here, (as a pure convenience thing), but we can
+* keep heap costs out of the hot path unless someone else is
+* using the pre-allocated buffer or the transfer is too large.
*/
- if ((n_tx + n_rx) > SPI_BUFSIZ)
- return -EINVAL;
+ if ((n_tx + n_rx) > SPI_BUFSIZ || !mutex_trylock()) {
+ local_buf = kmalloc(max(SPI_BUFSIZ, n_tx + n_rx), GFP_KERNEL);
+ if (!local_buf)
+ return -ENOMEM;
+ } else {
+ local_buf = buf;
+ }
spi_message_init();
memset(x, 0, sizeof x);
@@ -1664,14 +1670,6 @@ int spi_write_then_read(struct spi_device *spi,
spi_message_add_tail([1], );
}
- /* ... unless someone else is using the pre-allocated buffer */
- if (!mutex_trylock()) {
- local_buf = kmalloc(SPI_BUFSIZ, GFP_KERNEL);
- if (!local_buf)
- return -ENOMEM;
- } else
- local_buf = buf;
-
memcpy(local_buf, txbuf, n_tx);
x[0].tx_buf = local_buf;
x[1].rx_buf = local_buf + n_tx;
--
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: [ 64/66] GFS2: Test bufdata with buffer locked and gfs2_log_lock held
On Mon, 2012-11-26 at 15:13 +, Steven Whitehouse wrote:
> Hi,
>
> On Sun, 2012-11-25 at 14:11 +0100, Ben Hutchings wrote:
> > On Wed, 2012-11-14 at 20:11 -0800, Greg Kroah-Hartman wrote:
> > > 3.6-stable review patch. If anyone has any objections, please let me
> > > know.
> > >
> > > --
> > >
> > > From: Benjamin Marzinski
> > >
> > > commit 96e5d1d3adf56f1c7eeb07258f6a1a0a7ae9c489 upstream.
> > >
> > > In gfs2_trans_add_bh(), gfs2 was testing if a there was a bd attached to
> > > the
> > > buffer without having the gfs2_log_lock held. It was then assuming it
> > > would
> > > stay attached for the rest of the function. However, without either the
> > > log
> > > lock being held of the buffer locked, __gfs2_ail_flush() could detach bd
> > > at any
> > > time. This patch moves the locking before the test. If there isn't a bd
> > > already attached, gfs2 can safely allocate one and attach it before
> > > locking.
> > > There is no way that the newly allocated bd could be on the ail list,
> > > and thus no way for __gfs2_ail_flush() to detach it.
> > >
> > > Signed-off-by: Benjamin Marzinski
> > > Signed-off-by: Steven Whitehouse
> > > Signed-off-by: Greg Kroah-Hartman
> > [...]
> >
> > Is this needed for any earlier versions? It looks applicable to 3.2
> > (with minor changes).
> >
> > Ben.
> >
>
> Potentially yes, although I don't think we've had any reports from that
> far back,
OK, I've queued up this version for 3.2.
Ben.
---
From: Benjamin Marzinski
Date: Wed, 7 Nov 2012 00:38:06 -0600
Subject: GFS2: Test bufdata with buffer locked and gfs2_log_lock held
commit 96e5d1d3adf56f1c7eeb07258f6a1a0a7ae9c489 upstream.
In gfs2_trans_add_bh(), gfs2 was testing if a there was a bd attached to the
buffer without having the gfs2_log_lock held. It was then assuming it would
stay attached for the rest of the function. However, without either the log
lock being held of the buffer locked, __gfs2_ail_flush() could detach bd at any
time. This patch moves the locking before the test. If there isn't a bd
already attached, gfs2 can safely allocate one and attach it before locking.
There is no way that the newly allocated bd could be on the ail list,
and thus no way for __gfs2_ail_flush() to detach it.
Signed-off-by: Benjamin Marzinski
Signed-off-by: Steven Whitehouse
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings
---
fs/gfs2/lops.c | 14 ++
fs/gfs2/trans.c |8
2 files changed, 10 insertions(+), 12 deletions(-)
--- a/fs/gfs2/lops.c
+++ b/fs/gfs2/lops.c
@@ -165,16 +165,14 @@ static void buf_lo_add(struct gfs2_sbd *
struct gfs2_meta_header *mh;
struct gfs2_trans *tr;
- lock_buffer(bd->bd_bh);
- gfs2_log_lock(sdp);
if (!list_empty(>bd_list_tr))
- goto out;
+ return;
tr = current->journal_info;
tr->tr_touched = 1;
tr->tr_num_buf++;
list_add(>bd_list_tr, >tr_list_buf);
if (!list_empty(>le_list))
- goto out;
+ return;
set_bit(GLF_LFLUSH, >bd_gl->gl_flags);
set_bit(GLF_DIRTY, >bd_gl->gl_flags);
gfs2_meta_check(sdp, bd->bd_bh);
@@ -185,9 +183,6 @@ static void buf_lo_add(struct gfs2_sbd *
sdp->sd_log_num_buf++;
list_add(>le_list, >sd_log_le_buf);
tr->tr_num_buf_new++;
-out:
- gfs2_log_unlock(sdp);
- unlock_buffer(bd->bd_bh);
}
static void buf_lo_before_commit(struct gfs2_sbd *sdp)
@@ -518,11 +513,9 @@ static void databuf_lo_add(struct gfs2_s
struct address_space *mapping = bd->bd_bh->b_page->mapping;
struct gfs2_inode *ip = GFS2_I(mapping->host);
- lock_buffer(bd->bd_bh);
- gfs2_log_lock(sdp);
if (tr) {
if (!list_empty(>bd_list_tr))
- goto out;
+ return;
tr->tr_touched = 1;
if (gfs2_is_jdata(ip)) {
tr->tr_num_buf++;
@@ -530,7 +523,7 @@ static void databuf_lo_add(struct gfs2_s
}
}
if (!list_empty(>le_list))
- goto out;
+ return;
set_bit(GLF_LFLUSH, >bd_gl->gl_flags);
set_bit(GLF_DIRTY, >bd_gl->gl_flags);
@@ -542,9 +535,6 @@ static void databuf_lo_add(struct gfs2_s
} else {
list_add_tail(>le_list, >sd_log_le_ordered);
}
-out:
- gfs2_log_unlock(sdp);
- unlock_buffer(bd->bd_bh);
}
static void gfs2_check_magic(struct buffer_head *bh)
--- a/fs/gfs2/trans.c
+++ b/fs/gfs2/trans.c
@@ -145,14 +145,22 @@ void gfs2_trans_add_bh(struct gfs2_glock
struct gfs2_sbd *sdp = gl->gl_sbd;
struct gfs2_bufdata *bd;
+ lock_buffer(bh);
+ gfs2_log_lock(sdp);
bd = bh->b_private;
if (bd)
gfs2_assert(sdp, bd->bd_gl == gl);
else {
+ gfs2_log_unlock(sdp);
+ unlock_buffer(bh);
[PATCH 4/6] scsi: megaraid: remove a useless call to memset().
This call is followed by a call to memcpy() on the same memory area, so it can
be safely removed.
Signed-off-by: Cyril Roelandt
---
drivers/scsi/megaraid/megaraid_sas_fusion.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 74030af..71cc3eb 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -1028,8 +1028,6 @@ map_cmd_status(struct megasas_cmd_fusion *cmd, u8 status,
u8 ext_status)
cmd->scmd->result = (DID_OK << 16) | ext_status;
if (ext_status == SAM_STAT_CHECK_CONDITION) {
- memset(cmd->scmd->sense_buffer, 0,
- SCSI_SENSE_BUFFERSIZE);
memcpy(cmd->scmd->sense_buffer, cmd->sense,
SCSI_SENSE_BUFFERSIZE);
cmd->scmd->result |= DRIVER_SENSE << 24;
--
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 3/6] scsi: bnx2fc: remove useless calls to memset().
These calls are followed by calls to memcpy() on the same memory area, so they can be safely removed. Signed-off-by: Cyril Roelandt --- drivers/scsi/bnx2fc/bnx2fc_hwi.c |4 1 file changed, 4 deletions(-) diff --git a/drivers/scsi/bnx2fc/bnx2fc_hwi.c b/drivers/scsi/bnx2fc/bnx2fc_hwi.c index ef60afa..9be42b8 100644 --- a/drivers/scsi/bnx2fc/bnx2fc_hwi.c +++ b/drivers/scsi/bnx2fc/bnx2fc_hwi.c @@ -759,8 +759,6 @@ static void bnx2fc_process_unsol_compl(struct bnx2fc_rport *tgt, u16 wqe) case FCOE_ERROR_CODE_DATA_SOFN_SEQ_ACTIVE_RESET: BNX2FC_TGT_DBG(tgt, "REC TOV popped for xid - 0x%x\n", xid); - memset(_req->err_entry, 0, - sizeof(struct fcoe_err_report_entry)); memcpy(_req->err_entry, err_entry, sizeof(struct fcoe_err_report_entry)); if (!test_bit(BNX2FC_FLAG_SRR_SENT, @@ -847,8 +845,6 @@ ret_err_rqe: goto ret_warn_rqe; } - memset(_req->err_entry, 0, - sizeof(struct fcoe_err_report_entry)); memcpy(_req->err_entry, err_entry, sizeof(struct fcoe_err_report_entry)); -- 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: [ 05/56] drivers/leds/leds-lp5521.c: fix lp5521_read() error handling
On Fri, 2012-11-30 at 10:54 -0800, Greg Kroah-Hartman wrote:
> 3.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Dan Carpenter
>
> commit 5bc9ad774c063f6b41965e7314f2c26aa5e465a0 upstream.
>
> Gcc 4.6.2 complains that:
>
> drivers/leds/leds-lp5521.c: In function `lp5521_load_program':
> drivers/leds/leds-lp5521.c:214:21: warning: `mode' may be used
> uninitialized in this function [-Wuninitialized]
> drivers/leds/leds-lp5521.c: In function `lp5521_probe':
> drivers/leds/leds-lp5521.c:788:5: warning: `buf' may be used uninitialized
> in this function [-Wuninitialized]
> drivers/leds/leds-lp5521.c:740:6: warning: `ret' may be used uninitialized
> in this function [-Wuninitialized]
>
> These are real problems if lp5521_read() returns an error. When that
> happens we should handle it, instead of ignoring it or doing a bitwise
> OR with all the other error codes and continuing.
[...]
> --- a/drivers/leds/leds-lp5521.c
> +++ b/drivers/leds/leds-lp5521.c
[...]
> @@ -785,7 +789,7 @@ static int __devinit lp5521_probe(struct
>* LP5521_REG_ENABLE register will not have any effect - strange!
>*/
> ret = lp5521_read(client, LP5521_REG_R_CURRENT, );
> - if (buf != LP5521_REG_R_CURR_DEFAULT) {
> + if (ret || buf != LP5521_REG_R_CURR_DEFAULT) {
> dev_err(>dev, "error in resetting chip\n");
> goto fail2;
> }
lp5521_probe() is going to return 0 if ret == 0 &&
buf != LP5521_REG_R_CURR_DEFAULT here. It needs to set an error code.
Ben.
--
Ben Hutchings
It is easier to change the specification to fit the program than vice versa.
signature.asc
Description: This is a digitally signed message part
Re: [GIT PULL] Disintegrate UAPI for alpha [ver #2]
On Tue, Oct 09, 2012 at 10:15:08AM +0100, David Howells wrote: > Can you merge the following branch into the alpha tree please. > > This is to complete part of the UAPI disintegration for which the preparatory > patches were pulled recently. I think the alpha-next tree is currently inactive so nothing has happened regarding your merge request. Any chance you could send it directly to Linus? (A conflict has arisen in arch/alpha/include/asm/Kbuild against Linus' tree but that is easily resolved.) FWIW you can have my Acked-By but it would be better if one of the official Alpha maintainers acknowledged it. Cheers Michael. -- 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: Updating the .mailmap file
On Sat, 2012-12-01 at 19:50 +0100, Stefan Beller wrote: > Hello, > > I was just browsing the shortlog and it looked to > me as if there are many double entries, i.e. the same person > being there with multiple email addresses. > > So I wrote a script, which finds double names and adds them > to the .mailmap file. However manual checking, whether these > are really the same person is required. You should get together with Philipp Riemer. http://lkml.org/lkml/2012/5/3/98 I think it's a problem not really worth solving. -- 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/
[RFC] Capabilities still can't be inherited by normal programs
I'd like to be able to run programs (like bash!) as nonroot but with some capabilities granted. After all these years, it's almost, but not quite, possible. This is because the transition rule (if root isn't involved or NOROOT is set) is pP' = (pB' & fP) | (pI' & fI), and, when execing a program without vfs caps set, fI = 0. I want to set PR_SET_KEEPCAPS, setuid away from root, set some capability as inheritable, and exec something. That capability stays inheritable, but it doesn't end up permitted. Oops. (There's another alarming thing that happens -- programs end up with capability bits that are inheritable but not permitted. I'd like to change cap_bprm_set_creds to clear all inheritable bits that don't end up in the final permitted set to minimize confusion. Of course, this *could* (but seems unlikely to) trigger security bugs.) The obvious but scary fix is to make everything act like fI = if vfs caps aren't set. It's not immediately obvious why this would be bad: no task has any inheritable capabilities by default. Something like the sendmail bug is unlikely here -- this change would give *more* caps, not fewer, and it could be done in such a way that setuid binaries don't inherit caps. A less scary way would be to make it opt-in: set a securebit if you want default capability inheritance. This requires CAP_SETPCAP, which seems to be shorthand for "allow me to shoot myself in the foot". Sensible programs might set no_new_privs when they set this securebit. An even less scary way would be to require a new securebit *and* no_new_privs. Any suggestions? I'm happy to write patches, but I'd rather not cook up ten patches and have this get stuck in limbo for years. For some rationale: I want to write a program that has cap_net_raw permitted as a file capability. That program will do some checks and then invoke tcpdump. I can't do this: tcpdump can't inherit capabilities into its permitted set unless I set the cap_net_raw inheritable bit on it. --Andy P.S. The get_file_caps code is gross. Whatever the outcome of this discussion, I'll submit a patch to clean it up, and I'll probably add a file to Documentation/security for good measure. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] vt6656: remove a useless call to memset().
This call is followed by a call to memcpy() on the same memory area, so it can
be safely removed.
Signed-off-by: Cyril Roelandt
---
drivers/staging/vt6656/bssdb.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/vt6656/bssdb.c b/drivers/staging/vt6656/bssdb.c
index 6a13941..f9098b8 100644
--- a/drivers/staging/vt6656/bssdb.c
+++ b/drivers/staging/vt6656/bssdb.c
@@ -240,7 +240,6 @@ pDevice->bSameBSSMaxNum = jj;
pSelect->bSelected = TRUE;
if (pDevice->bRoaming == FALSE) {
// Einsn Add @20070907
- memset(pbyDesireSSID, 0, WLAN_IEHDR_LEN +
WLAN_SSID_MAXLEN + 1);
memcpy(pbyDesireSSID,pCurrBSS->abySSID,WLAN_IEHDR_LEN +
WLAN_SSID_MAXLEN + 1) ;
}
--
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/6] rtl8712: remove useless calls to memset().
These calls are followed by calls to memcpy() on the same memory area, so they can be safely removed. Signed-off-by: Cyril Roelandt --- drivers/staging/rtl8712/mlme_linux.c|2 -- drivers/staging/rtl8712/rtl871x_cmd.c |1 - drivers/staging/rtl8712/rtl871x_ioctl_set.c |2 -- drivers/staging/rtl8712/rtl871x_mlme.c |5 - 4 files changed, 10 deletions(-) diff --git a/drivers/staging/rtl8712/mlme_linux.c b/drivers/staging/rtl8712/mlme_linux.c index 7279854..f569a70 100644 --- a/drivers/staging/rtl8712/mlme_linux.c +++ b/drivers/staging/rtl8712/mlme_linux.c @@ -106,8 +106,6 @@ void r8712_os_indicate_disconnect(struct _adapter *adapter) * disconnect with AP for 60 seconds. */ - memset([0], 0x00, sizeof( - struct RT_PMKID_LIST) * NUM_PMKID_CACHE); memcpy([0], >securitypriv. PMKIDList[0], sizeof(struct RT_PMKID_LIST) * NUM_PMKID_CACHE); diff --git a/drivers/staging/rtl8712/rtl871x_cmd.c b/drivers/staging/rtl8712/rtl871x_cmd.c index 31f31dbf..f16307f 100644 --- a/drivers/staging/rtl8712/rtl871x_cmd.c +++ b/drivers/staging/rtl8712/rtl871x_cmd.c @@ -525,7 +525,6 @@ u8 r8712_joinbss_cmd(struct _adapter *padapter, struct wlan_network *pnetwork) kfree(pcmd); return _FAIL; } - memset(psecnetwork, 0, t_len); memcpy(psecnetwork, >network, t_len); auth = >authenticator_ie[0]; psecuritypriv->authenticator_ie[0] = (unsigned char) diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_set.c b/drivers/staging/rtl8712/rtl871x_ioctl_set.c index d3ab24e..53a7c8c 100644 --- a/drivers/staging/rtl8712/rtl871x_ioctl_set.c +++ b/drivers/staging/rtl8712/rtl871x_ioctl_set.c @@ -97,8 +97,6 @@ static u8 do_join(struct _adapter *padapter) pmlmepriv->fw_state = WIFI_ADHOC_MASTER_STATE; pibss = padapter->registrypriv.dev_network. MacAddress; - memset(_network->Ssid, 0, - sizeof(struct ndis_802_11_ssid)); memcpy(_network->Ssid, >assoc_ssid, sizeof(struct ndis_802_11_ssid)); diff --git a/drivers/staging/rtl8712/rtl871x_mlme.c b/drivers/staging/rtl8712/rtl871x_mlme.c index c51ad9e..e52f04d 100644 --- a/drivers/staging/rtl8712/rtl871x_mlme.c +++ b/drivers/staging/rtl8712/rtl871x_mlme.c @@ -604,9 +604,6 @@ void r8712_surveydone_event_callback(struct _adapter *adapter, u8 *pbuf) adapter->registrypriv. dev_network.MacAddress; pmlmepriv->fw_state ^= _FW_UNDER_SURVEY; - memset(_network->Ssid, 0, - sizeof(struct - ndis_802_11_ssid)); memcpy(_network->Ssid, >assoc_ssid, sizeof(struct @@ -1006,8 +1003,6 @@ void r8712_stadel_event_callback(struct _adapter *adapter, u8 *pbuf) memcpy(pdev_network, _network->network, r8712_get_ndis_wlan_bssid_ex_sz(_network-> network)); - memset(_network->Ssid, 0, - sizeof(struct ndis_802_11_ssid)); memcpy(_network->Ssid, >assoc_ssid, sizeof(struct ndis_802_11_ssid)); -- 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/6] bna: remove useless calls to memset().
These calls are followed by calls to memcpy() on the same memory area, so they
can safely be removed.
Signed-off-by: Cyril Roelandt
---
drivers/net/ethernet/brocade/bna/bfa_ioc.c |4
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/brocade/bna/bfa_ioc.c
b/drivers/net/ethernet/brocade/bna/bfa_ioc.c
index 959c58e..3227fdd 100644
--- a/drivers/net/ethernet/brocade/bna/bfa_ioc.c
+++ b/drivers/net/ethernet/brocade/bna/bfa_ioc.c
@@ -2273,7 +2273,6 @@ bfa_ioc_get_type(struct bfa_ioc *ioc)
static void
bfa_ioc_get_adapter_serial_num(struct bfa_ioc *ioc, char *serial_num)
{
- memset(serial_num, 0, BFA_ADAPTER_SERIAL_NUM_LEN);
memcpy(serial_num,
(void *)ioc->attr->brcd_serialnum,
BFA_ADAPTER_SERIAL_NUM_LEN);
@@ -2282,7 +2281,6 @@ bfa_ioc_get_adapter_serial_num(struct bfa_ioc *ioc, char
*serial_num)
static void
bfa_ioc_get_adapter_fw_ver(struct bfa_ioc *ioc, char *fw_ver)
{
- memset(fw_ver, 0, BFA_VERSION_LEN);
memcpy(fw_ver, ioc->attr->fw_version, BFA_VERSION_LEN);
}
@@ -2304,7 +2302,6 @@ bfa_ioc_get_pci_chip_rev(struct bfa_ioc *ioc, char
*chip_rev)
static void
bfa_ioc_get_adapter_optrom_ver(struct bfa_ioc *ioc, char *optrom_ver)
{
- memset(optrom_ver, 0, BFA_VERSION_LEN);
memcpy(optrom_ver, ioc->attr->optrom_version,
BFA_VERSION_LEN);
}
@@ -2312,7 +2309,6 @@ bfa_ioc_get_adapter_optrom_ver(struct bfa_ioc *ioc, char
*optrom_ver)
static void
bfa_ioc_get_adapter_manufacturer(struct bfa_ioc *ioc, char *manufacturer)
{
- memset(manufacturer, 0, BFA_ADAPTER_MFG_NAME_LEN);
memcpy(manufacturer, BFA_MFG_NAME, BFA_ADAPTER_MFG_NAME_LEN);
}
--
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/6] scsi: bfa: remove useless calls to memset().
These calls are followed by calls to memcpy() on the same memory area, so they
can safely be removed.
Signed-off-by: Cyril Roelandt
---
drivers/scsi/bfa/bfa_ioc.c |1 -
drivers/scsi/bfa/bfad_bsg.c |1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/scsi/bfa/bfa_ioc.c b/drivers/scsi/bfa/bfa_ioc.c
index 0116c10..dd2a2ef 100644
--- a/drivers/scsi/bfa/bfa_ioc.c
+++ b/drivers/scsi/bfa/bfa_ioc.c
@@ -2517,7 +2517,6 @@ bfa_ioc_get_type(struct bfa_ioc_s *ioc)
void
bfa_ioc_get_adapter_serial_num(struct bfa_ioc_s *ioc, char *serial_num)
{
- memset((void *)serial_num, 0, BFA_ADAPTER_SERIAL_NUM_LEN);
memcpy((void *)serial_num,
(void *)ioc->attr->brcd_serialnum,
BFA_ADAPTER_SERIAL_NUM_LEN);
diff --git a/drivers/scsi/bfa/bfad_bsg.c b/drivers/scsi/bfa/bfad_bsg.c
index 555e7db..9527fdb 100644
--- a/drivers/scsi/bfa/bfad_bsg.c
+++ b/drivers/scsi/bfa/bfad_bsg.c
@@ -3197,7 +3197,6 @@ bfad_fcxp_map_sg(struct bfad_s *bfad, void *payload_kbuf,
goto out_free_mem;
/* copy the linear bsg buffer to buf_info */
- memset(buf_info->virt, 0, buf_info->size);
memcpy(buf_info->virt, payload_kbuf, buf_info->size);
/*
--
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 0/6] Remove useless calls to memset().
The following six patches remove useless calls to memset(). They have been found with this Coccinelle script: @@ expression E; expression S; @@ -memset(E, 0, S); memcpy(E, ..., S); They have only been tested by compilation. WBR, Cyril Roelandt. Cyril Roelandt (6): bna: remove useless calls to memset(). scsi: bfa: remove useless calls to memset(). scsi: bnx2fc: remove useless calls to memset(). scsi: megaraid: remove a useless call to memset(). rtl8712: remove useless calls to memset(). vt6656: remove a useless call to memset(). drivers/net/ethernet/brocade/bna/bfa_ioc.c |4 drivers/scsi/bfa/bfa_ioc.c |1 - drivers/scsi/bfa/bfad_bsg.c |1 - drivers/scsi/bnx2fc/bnx2fc_hwi.c|4 drivers/scsi/megaraid/megaraid_sas_fusion.c |2 -- drivers/staging/rtl8712/mlme_linux.c|2 -- drivers/staging/rtl8712/rtl871x_cmd.c |1 - drivers/staging/rtl8712/rtl871x_ioctl_set.c |2 -- drivers/staging/rtl8712/rtl871x_mlme.c |5 - drivers/staging/vt6656/bssdb.c |1 - 10 files changed, 23 deletions(-) -- 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/2] mfd: wm5102: Add tuning for revision B
Evaluation of revision B of WM5102 suggests updates to the register patch
for optimal performance, and make this the default behaviour for new
devices.
Signed-off-by: Mark Brown
---
drivers/mfd/wm5102-tables.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/wm5102-tables.c b/drivers/mfd/wm5102-tables.c
index 8bd0504..36708b0 100644
--- a/drivers/mfd/wm5102-tables.c
+++ b/drivers/mfd/wm5102-tables.c
@@ -56,6 +56,18 @@ static const struct reg_default wm5102_reva_patch[] = {
{ 0x80, 0x },
};
+static const struct reg_default wm5102_revb_patch[] = {
+ { 0x80, 0x0003 },
+ { 0x081, 0xE022 },
+ { 0x410, 0x6080 },
+ { 0x418, 0x6080 },
+ { 0x420, 0x6080 },
+ { 0x428, 0xC000 },
+ { 0x441, 0x8014 },
+ { 0x458, 0x000b },
+ { 0x80, 0x },
+};
+
/* We use a function so we can use ARRAY_SIZE() */
int wm5102_patch(struct arizona *arizona)
{
@@ -65,7 +77,9 @@ int wm5102_patch(struct arizona *arizona)
wm5102_reva_patch,
ARRAY_SIZE(wm5102_reva_patch));
default:
- return 0;
+ return regmap_register_patch(arizona->regmap,
+wm5102_revb_patch,
+ARRAY_SIZE(wm5102_revb_patch));
}
}
--
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] mfd: arizona: Defer patch initialistation until after first device boot
Make sure that we don't race with the initial device boot by only doing
the initialisation after we've waited for the boot to complete.
The runtime PM code already waits for the boot to complete before it
syncs the register patches so in most systems if a race does occur we will
power down very soon afterwards and recover anyway.
Reported-by: Charles Keepax
Signed-off-by: Mark Brown
---
drivers/mfd/arizona-core.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index c784f46..bc8a3ed 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -292,6 +292,7 @@ int arizona_dev_init(struct arizona *arizona)
struct device *dev = arizona->dev;
const char *type_name;
unsigned int reg, val;
+ int (*apply_patch)(struct arizona *) = NULL;
int ret, i;
dev_set_drvdata(arizona->dev, arizona);
@@ -391,7 +392,7 @@ int arizona_dev_init(struct arizona *arizona)
arizona->type);
arizona->type = WM5102;
}
- ret = wm5102_patch(arizona);
+ apply_patch = wm5102_patch;
break;
#endif
#ifdef CONFIG_MFD_WM5110
@@ -402,7 +403,7 @@ int arizona_dev_init(struct arizona *arizona)
arizona->type);
arizona->type = WM5110;
}
- ret = wm5110_patch(arizona);
+ apply_patch = wm5110_patch;
break;
#endif
default:
@@ -412,9 +413,6 @@ int arizona_dev_init(struct arizona *arizona)
dev_info(dev, "%s revision %c\n", type_name, arizona->rev + 'A');
- if (ret != 0)
- dev_err(arizona->dev, "Failed to apply patch: %d\n", ret);
-
/* If we have a /RESET GPIO we'll already be reset */
if (!arizona->pdata.reset) {
regcache_mark_dirty(arizona->regmap);
@@ -438,6 +436,15 @@ int arizona_dev_init(struct arizona *arizona)
goto err_reset;
}
+ if (apply_patch) {
+ ret = apply_patch(arizona);
+ if (ret != 0) {
+ dev_err(arizona->dev, "Failed to apply patch: %d\n",
+ ret);
+ goto err_reset;
+ }
+ }
+
for (i = 0; i < ARRAY_SIZE(arizona->pdata.gpio_defaults); i++) {
if (!arizona->pdata.gpio_defaults[i])
continue;
--
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 1/2] mfd: arizona: Defer patch initialistation until after first device boot
On Sun, Dec 02, 2012 at 02:11:51AM +0900, Mark Brown wrote: > Make sure that we don't race with the initial device boot by only doing > the initialisation after we've waited for the boot to complete. This is broken, will send a fixed version soon. signature.asc Description: Digital signature
RE: [PATCH 2/4] Input: RMI4 - move sensor driver and F01 handler into the core
Sorry for top posting this - I forgot to email while still at work. I've been poking at this, and think (a) it's possible that I'm being too paranoid, and (b) it looks like it'll work with some of the future stuff. So I'll back off my objections for the moment, and give these changes a try, possibly with some slight modifications. Thanks! Chris From: linux-input-ow...@vger.kernel.org [linux-input-ow...@vger.kernel.org] on behalf of Dmitry Torokhov [dmitry.torok...@gmail.com] Sent: Thursday, November 29, 2012 9:21 AM To: Christopher Heiny Cc: Linus Walleij; Linux Input; Linux Kernel; Allie Xiong; Vivian Ly; Daniel Rosenberg; Alexandra Chin; Joerie de Gram; Wolfram Sang; Mathieu Poirier Subject: Re: [PATCH 2/4] Input: RMI4 - move sensor driver and F01 handler into the core Hi Chris, On Wed, Nov 28, 2012 at 08:54:32PM -0800, Christopher Heiny wrote: > On 11/27/2012 01:21 AM, Dmitry Torokhov wrote: > >There is no point in having the sensor driver and F01 handler separate > >from the RMI core since it is not useful without them and having them > >all together simplifies initialization among other things. > > Hi Dmitry, > > I've been looking at this patch as well as your patch 3/4 changes, > and I'm not sure it's for the better. > > One thing that confuses me is that these appear to go against the > advice we've been getting over the past months to rely more on > standard kernel bus and driver implementations, instead of the > "roll-your-own" implementation we had been using before. > > More importantly, the patches inextricably link the sensor driver > implementation and the F01 driver implementation to the bus > implementation, and means that any given system can have only one > way of managing F01. As you observed, a sensor is pretty much > useless without an F01 handler, but I am reasonably sure that there > will be future systems that have more than one RMI4 sensor in them, > and there is a strong possibility that these sensors may have > different requirements for handling F01. In the near future, then, > these changes will have to be refactored back to something more like > the structure of our 2012/11/16 patch set. > > Additionally, having F01 as a special case means that when we start > implementing things such as support for request_firmware(), there > will have to be a bunch of special case code to deal with F01, since > it's no longer "just another function driver". That seems to go in > exactly the opposite direction of the simplification that you're > trying to achieve. But F01 continues to being "just another function driver" even with my changes. It is still registered as rmi_fucntion_handler and uses standard matching mechanisms to bind to rmi_functions registered by the sensor driver. What I changed is the fact that rmi_f01 is no longer a separate module which could be loaded after loading rmi_bus and it can't be unloaded without unloading rmi_bus. This simplifies things and makes it easier to have rmi core compiled as a module. Also I do not quite follow your idea that devices might have different requirements for handling F01. If that is true then be _can't_ implement "F01" as "another function driver"... But that is orthogonal for the 3/4 change we are discussing here. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/54] 3.6.9-stable review
On Sat, Dec 1, 2012 at 9:50 AM, Greg Kroah-Hartman wrote: > On Sat, Dec 01, 2012 at 11:58:28PM +0900, Satoru Takeuchi wrote: >> At Fri, 30 Nov 2012 10:55:31 -0800, >> Greg Kroah-Hartman wrote: >> > >> > This is the start of the stable review cycle for the 3.6.9 release. >> > There are 54 patches in this series, all will be posted as a response >> > to this one. If anyone has any issues with these being applied, please >> > let me know. >> > >> > Responses should be made by Sun Dec 2 18:51:00 UTC 2012. >> > Anything received after that time might be too late. >> > >> > The whole patch series can be found in one patch at: >> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.6.9-rc1.gz >> > and the diffstat can be found below. >> >> 3.6.9-rc1 can be built and boot without any problem. Building a kernel with >> this kernel also works fine. > > Great, thanks for testing all three of these trees out and letting me > know. Patch applied cleanly, compiled and booted on the following systems: HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics Cross-compile tests passed on the following architectures: alpha arm c6x mips powerpc sh sparc tile If you would like to see more architectures cross-compiled and on all releases, please let me know. I just did the cross-compiles on 3.6.y -- Shuah -- 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: [ 00/56] 3.4.21-stable review
On Sat, Dec 1, 2012 at 8:35 AM, Satoru Takeuchi wrote: > At Fri, 30 Nov 2012 10:54:52 -0800, > Greg Kroah-Hartman wrote: >> >> This is the start of the stable review cycle for the 3.4.21 release. >> There are 56 patches in this series, all will be posted as a response >> to this one. If anyone has any issues with these being applied, please >> let me know. >> >> Responses should be made by Sun Dec 2 18:50:02 UTC 2012. >> Anything received after that time might be too late. >> >> The whole patch series can be found in one patch at: >> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.21-rc1.gz >> and the diffstat can be found below. > > 3.4.21-rc1 can be built and boot without any problem. Building a kernel with > this kernel also works fine. > Patch applied cleanly, compiled and booted on the following systems: HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics -- Shuah -- 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: [ 00/37] 3.0.54-stable review
On Fri, Nov 30, 2012 at 11:45 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.0.54 release. > There are 37 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Dec 2 18:36:43 UTC 2012. > Anything received after that time might be too late. > Patch applied cleanly, compiled and booted on the following systems: HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics -- Shuah -- 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] fs:ext3: remove lock_buffer in bclean() and setup_new_group_blocks
it's not necessary to lock the buffers because no one touches them
beyond the file system.
Signed-off-by: Cong Ding
---
fs/ext3/resize.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/fs/ext3/resize.c b/fs/ext3/resize.c
index 0f814f3..f76fcd6 100644
--- a/fs/ext3/resize.c
+++ b/fs/ext3/resize.c
@@ -122,10 +122,8 @@ static struct buffer_head *bclean(handle_t *handle, struct
super_block *sb,
brelse(bh);
bh = ERR_PTR(err);
} else {
- lock_buffer(bh);
memset(bh->b_data, 0, sb->s_blocksize);
set_buffer_uptodate(bh);
- unlock_buffer(bh);
}
return bh;
@@ -242,10 +240,8 @@ static int setup_new_group_blocks(struct super_block *sb,
brelse(gdb);
goto exit_bh;
}
- lock_buffer(gdb);
memcpy(gdb->b_data, sbi->s_group_desc[i]->b_data, gdb->b_size);
set_buffer_uptodate(gdb);
- unlock_buffer(gdb);
err = ext3_journal_dirty_metadata(handle, gdb);
if (err) {
brelse(gdb);
--
1.7.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] vhost-blk: Add vhost-blk support v6
vhost-blk is an in-kernel virito-blk device accelerator.
Due to lack of proper in-kernel AIO interface, this version converts
guest's I/O request to bio and use submit_bio() to submit I/O directly.
So this version any supports raw block device as guest's disk image,
e.g. /dev/sda, /dev/ram0. We can add file based image support to
vhost-blk once we have in-kernel AIO interface. There are some work in
progress for in-kernel AIO interface from Dave Kleikamp and Zach Brown:
http://marc.info/?l=linux-fsdevel=133312234313122
Performance evaluation:
-
LKVM: Fio with libaio ioengine on 1 Fusion IO device
IOPS(k)BeforeAfterImprovement
seq-read 107 121 +13.0%
seq-write 130 179 +37.6%
rnd-read 102 122 +19.6%
rnd-write 125 159 +27.0%
QEMU: Fio with libaio ioengine on 1 Fusion IO device
IOPS(k)BeforeAfterImprovement
seq-read 76123 +61.8%
seq-write 139 173 +24.4%
rnd-read 73120 +64.3%
rnd-write 75156 +108.0%
QEMU: Fio with libaio ioengine on 1 Ramdisk device
IOPS(k)BeforeAfterImprovement
seq-read 138 437 +216%
seq-write 191 436 +128%
rnd-read 137 426 +210%
rnd-write 140 415 +196%
QEMU: Fio with libaio ioengine on 8 Ramdisk device
50% read + 50% write
IOPS(k)BeforeAfterImprovement
randrw 64/64 189/189 +195%/+195%
Userspace bits:
-
1) LKVM
The latest vhost-blk userspace bits for kvm tool can be found here:
g...@github.com:asias/linux-kvm.git blk.vhost-blk
2) QEMU
The latest vhost-blk userspace prototype for QEMU can be found here:
g...@github.com:asias/qemu.git blk.vhost-blk
Changes in v6:
- Use inline req_page_list to reduce kmalloc
- Switch to single thread model, thanks mst!
- Wait until requests fired before vhost_blk_flush to be finished
Changes in v5:
- Do not assume the buffer layout
- Fix wakeup race
Changes in v4:
- Mark req->status as userspace pointer
- Use __copy_to_user() instead of copy_to_user() in vhost_blk_set_status()
- Add if (need_resched()) schedule() in blk thread
- Kill vhost_blk_stop_vq() and move it into vhost_blk_stop()
- Use vq_err() instead of pr_warn()
- Fail un Unsupported request
- Add flush in vhost_blk_set_features()
Changes in v3:
- Sending REQ_FLUSH bio instead of vfs_fsync, thanks Christoph!
- Check file passed by user is a raw block device file
Acked-by: David S. Miller
Signed-off-by: Asias He
---
drivers/vhost/Kconfig | 1 +
drivers/vhost/Kconfig.blk | 10 +
drivers/vhost/Makefile| 2 +
drivers/vhost/blk.c | 724 ++
drivers/vhost/blk.h | 8 +
5 files changed, 745 insertions(+)
create mode 100644 drivers/vhost/Kconfig.blk
create mode 100644 drivers/vhost/blk.c
create mode 100644 drivers/vhost/blk.h
diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
index 202bba6..acd8038 100644
--- a/drivers/vhost/Kconfig
+++ b/drivers/vhost/Kconfig
@@ -11,4 +11,5 @@ config VHOST_NET
if STAGING
source "drivers/vhost/Kconfig.tcm"
+source "drivers/vhost/Kconfig.blk"
endif
diff --git a/drivers/vhost/Kconfig.blk b/drivers/vhost/Kconfig.blk
new file mode 100644
index 000..ff8ab76
--- /dev/null
+++ b/drivers/vhost/Kconfig.blk
@@ -0,0 +1,10 @@
+config VHOST_BLK
+ tristate "Host kernel accelerator for virtio blk (EXPERIMENTAL)"
+ depends on BLOCK && EXPERIMENTAL && m
+ ---help---
+ This kernel module can be loaded in host kernel to accelerate
+ guest block with virtio_blk. Not to be confused with virtio_blk
+ module itself which needs to be loaded in guest kernel.
+
+ To compile this driver as a module, choose M here: the module will
+ be called vhost_blk.
diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
index a27b053..1a8a4a5 100644
--- a/drivers/vhost/Makefile
+++ b/drivers/vhost/Makefile
@@ -2,3 +2,5 @@ obj-$(CONFIG_VHOST_NET) += vhost_net.o
vhost_net-y := vhost.o net.o
obj-$(CONFIG_TCM_VHOST) += tcm_vhost.o
+obj-$(CONFIG_VHOST_BLK) += vhost_blk.o
+vhost_blk-y := blk.o
diff --git a/drivers/vhost/blk.c b/drivers/vhost/blk.c
new file mode 100644
index 000..e4ca4b6
--- /dev/null
+++ b/drivers/vhost/blk.c
@@ -0,0 +1,724 @@
+/*
+ * Copyright (C) 2011 Taobao, Inc.
+ * Author: Liu Yuan
+ *
+ * Copyright (C) 2012 Red Hat, Inc.
+ * Author: Asias He
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.
+ *
+ * virtio-blk server in host kernel.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "vhost.c"
+#include "vhost.h"
+#include "blk.h"
+
+static DEFINE_IDA(vhost_blk_index_ida);
+
+enum {
+ VHOST_BLK_VQ_REQ = 0,
+ VHOST_BLK_VQ_MAX = 1,
+};
+
+struct req_page_list {
+ struct page **pages;
+ int pages_nr;
+};
+
+#define NR_INLINE 16
+
+struct
[PATCH] workqueue: mod_delayed_work_on() shouldn't queue timer on 0 delay
>From 8852aac25e79e38cc6529f20298eed154f60b574 Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Sat, 1 Dec 2012 16:23:42 -0800
8376fe22c7 ("workqueue: implement mod_delayed_work[_on]()")
implemented mod_delayed_work[_on]() using the improved
try_to_grab_pending(). The function is later used, among others, to
replace [__]candel_delayed_work() + queue_delayed_work() combinations.
Unfortunately, a delayed_work item w/ zero @delay is handled slightly
differently by mod_delayed_work_on() compared to
queue_delayed_work_on(). The latter skips timer altogether and
directly queues it using queue_work_on() while the former schedules
timer which will expire on the closest tick. This means, when @delay
is zero, that [__]cancel_delayed_work() + queue_delayed_work_on()
makes the target item immediately executable while
mod_delayed_work_on() may induce delay of upto a full tick.
This somewhat subtle difference breaks some of the converted users.
e.g. block queue plugging uses delayed_work for deferred processing
and uses mod_delayed_work_on() when the queue needs to be immediately
unplugged. The above problem manifested as noticeably higher number
of context switches under certain circumstances.
The difference in behavior was caused by missing special case handling
for 0 delay in mod_delayed_work_on() compared to
queue_delayed_work_on(). Joonsoo Kim posted a patch to add it -
("workqueue: optimize mod_delayed_work_on() when @delay == 0")[1].
The patch was queued for 3.8 but it was described as optimization and
I missed that it was a correctness issue.
As both queue_delayed_work_on() and mod_delayed_work_on() use
__queue_delayed_work() for queueing, it seems that the better approach
is to move the 0 delay special handling to the function instead of
duplicating it in mod_delayed_work_on().
Fix the problem by moving 0 delay special case handling from
queue_delayed_work_on() to __queue_delayed_work(). This replaces
Joonsoo's patch.
[1] http://thread.gmane.org/gmane.linux.kernel/1379011/focus=1379012
Signed-off-by: Tejun Heo
Reported-and-tested-by: Anders Kaseorg
Reported-and-tested-by: Zlatko Calusic
LKML-Reference:
LKML-Reference: <50a78aa9.5040...@iskon.hr>
Cc: Joonsoo Kim
---
Applied to wq/for-3.7-fixes. Pull request sent.
Thanks!
kernel/workqueue.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index ac25db1..084aa47 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1364,6 +1364,17 @@ static void __queue_delayed_work(int cpu, struct
workqueue_struct *wq,
BUG_ON(timer_pending(timer));
BUG_ON(!list_empty(>entry));
+ /*
+* If @delay is 0, queue @dwork->work immediately. This is for
+* both optimization and correctness. The earliest @timer can
+* expire is on the closest next tick and delayed_work users depend
+* on that there's no such delay when @delay is 0.
+*/
+ if (!delay) {
+ __queue_work(cpu, wq, >work);
+ return;
+ }
+
timer_stats_timer_set_start_info(>timer);
/*
@@ -1417,9 +1428,6 @@ bool queue_delayed_work_on(int cpu, struct
workqueue_struct *wq,
bool ret = false;
unsigned long flags;
- if (!delay)
- return queue_work_on(cpu, wq, >work);
-
/* read the comment in __queue_work() */
local_irq_save(flags);
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] workqueue fixes for 3.7-rc7
Hello, Linus.
Unfortunately, I have two really late fixes. One was for a
long-standing bug and queued for 3.8 but I found out about a
regression introduced during 3.7-rc1 two days ago, so I'm sending out
the two fixes together.
The first (long-standing) one is rescuer_thread() entering exit path
w/ TASK_INTERRUPTIBLE. It only triggers on workqueue destructions
which isn't very frequent and the exit path can usually survive being
called with TASK_INTERRUPT, so it was hidden pretty well. Apparently,
if you're reiserfs, this could lead to the exiting kthread sleeping
indefinitely holding a mutex, which is never good. The fix is simple
- restoring TASK_RUNNING before returning from the kthread function.
The second one is introduced by the new mod_delayed_work().
mod_delayed_work() was missing special case handling for 0 delay.
Instead of queueing the work item immediately, it queued the timer
which expires on the closest next tick. Some users of the new
function converted from "[__]cancel_delayed_work() +
queue_delayed_work()" combination became unhappy with the extra delay.
Block unplugging led to noticeably higher number of context switches
and intel 6250 wireless failed to associate with WPA-Enterprise
network. The fix, again, is fairly simple. The 0 delay special case
logic from queue_delayed_work_on() should be moved to
__queue_delayed_work() which is shared by both queue_delayed_work_on()
and mod_delayed_work_on().
The first one is difficult to trigger and the failure mode for the
latter isn't completely catastrophic, so missing these two for 3.7
wouldn't make it a disastrous release, but both bugs are nasty and the
fixes are fairly safe, so please consider pulling the following
branch.
git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-3.7-fixes
Thanks.
---
Mike Galbraith (1):
workqueue: exit rescuer_thread() as TASK_RUNNING
Tejun Heo (1):
workqueue: mod_delayed_work_on() shouldn't queue timer on 0 delay
kernel/workqueue.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 042d221..084aa47 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1364,6 +1364,17 @@ static void __queue_delayed_work(int cpu, struct
workqueue_struct *wq,
BUG_ON(timer_pending(timer));
BUG_ON(!list_empty(>entry));
+ /*
+* If @delay is 0, queue @dwork->work immediately. This is for
+* both optimization and correctness. The earliest @timer can
+* expire is on the closest next tick and delayed_work users depend
+* on that there's no such delay when @delay is 0.
+*/
+ if (!delay) {
+ __queue_work(cpu, wq, >work);
+ return;
+ }
+
timer_stats_timer_set_start_info(>timer);
/*
@@ -1417,9 +1428,6 @@ bool queue_delayed_work_on(int cpu, struct
workqueue_struct *wq,
bool ret = false;
unsigned long flags;
- if (!delay)
- return queue_work_on(cpu, wq, >work);
-
/* read the comment in __queue_work() */
local_irq_save(flags);
@@ -2407,8 +2415,10 @@ static int rescuer_thread(void *__wq)
repeat:
set_current_state(TASK_INTERRUPTIBLE);
- if (kthread_should_stop())
+ if (kthread_should_stop()) {
+ __set_current_state(TASK_RUNNING);
return 0;
+ }
/*
* See whether any cpu is asking for help. Unbounded
--
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: [ 00/37] 3.0.54-stable review
Dave, Shuah, At Sat, 1 Dec 2012 10:15:21 -0700, Shuah Khan wrote: > > On Sat, Dec 1, 2012 at 9:24 AM, David Miller wrote: > > > > Satoru, I just want to let you know that, because you encode your > > emails using ISO-2022-JP-2, nearly half of the subscribers to > > the vger.kernel.org mailing lists bounce your postings. > > > > I know it's stupid, and it's mostly a Microsoft Exchange issue, > > but it does mean that people that you may wish to see your emails > > are not. This includes developers at major sites such as cisco.com > > and intel.com > > > > I even saw toshiba.co.jp bounce your postings because of this encoding > > issue. > > > > Anyways, just FYI... > > Satoru, > > hp.com addresses have the same issue and I keep cc'ing all my emails > from hp.com to my gmail address so I don't miss any responses. Again > just FYI. Thank you for let me know about it. Probably it's because "User-Agent" header in my mail contains a non-ascii character. I fixed this header and this problem would be fixed now. Thanks, Satoru -- 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: Wireless regression in workqueue: use mod_delayed_work() instead of __cancel + queue
On Sat, 1 Dec 2012, Tejun Heo wrote:
> Can you please test this one too? Thanks!
>
> […]
> + if (!delay) {
> + __queue_work(cpu, wq, >work);
> + return;
> + }
> +
> […]
> - if (!delay)
> - return queue_work_on(cpu, wq, >work);
> -
Yes, this one fixes the bug too (on v3.7.0-rc7).
Anders
--
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/
Brightness control fails between 3.6.8 and 3.7.0-rc7 (Intel 915/Dell Vostro 3560)
Hello all, Somewhere between v3.6.8 [vanilla] and 3.7.0-rc7 the ability to control the LCD brightness was broken on this laptop [details below]. Basically it locks the brightness as full brightness and cannot be changed. It works properly in v3.6.8 though [and below...]. Details: 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Dell Device 056e Flags: bus master, fast devsel, latency 0, IRQ 44 Memory at c300 (64-bit, non-prefetchable) [size=4M] Memory at b000 (64-bit, prefetchable) [size=256M] I/O ports at 5000 [size=64] Expansion ROM at [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 This is on a Dell Vostro 3560/0C05GV I have the discrete radeon turned off [via vgaswitcheroo]. I have dell_wmi and dell_laptop loaded. I use the same kernel config between the two builds. Tom -- 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] fs:ext4:hash.c: reduce one "if" comparison
it is unnecessary to check i<4 after the loop. just do it before the break.
Signed-off-by: Cong Ding
---
fs/ext4/hash.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/ext4/hash.c b/fs/ext4/hash.c
index fa8e491..3d586f0 100644
--- a/fs/ext4/hash.c
+++ b/fs/ext4/hash.c
@@ -155,11 +155,11 @@ int ext4fs_dirhash(const char *name, int len, struct
dx_hash_info *hinfo)
/* Check to see if the seed is all zero's */
if (hinfo->seed) {
for (i = 0; i < 4; i++) {
- if (hinfo->seed[i])
+ if (hinfo->seed[i]) {
+ memcpy(buf, hinfo->seed, sizeof(buf));
break;
+ }
}
- if (i < 4)
- memcpy(buf, hinfo->seed, sizeof(buf));
}
switch (hinfo->hash_version) {
--
1.7.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: mmp: select PINCTRL for ARCH_MMP
On Wed, Nov 28, 2012 at 7:42 AM, Axel Lin wrote: > This makes PINCTRL related config options visible. > Otherwise there is no way to build pinctrl drivers for MMP2, PXA168 and > PXA910. > > Signed-off-by: Axel Lin > --- > This patch was sent on https://lkml.org/lkml/2012/11/12/10 > Resend to Haojian's correct email address. Applies this as well as an obvious fix. ACK:s accepted... Yours, Linus Walleij -- 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 RESEND] pinctrl: Drop selecting PINCONF for MMP2, PXA168 and PXA910
On Wed, Nov 28, 2012 at 7:37 AM, Axel Lin wrote: > These drivers do not need to select PINCONF. > > Signed-off-by: Axel Lin > --- > This patch was sent on https://lkml.org/lkml/2012/11/12/12. > Resend to Haojian's correct email address. Applied. PXA guys can scream if they don't like it :-) Yours, Linus Walleij -- 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] pinctrl: exynos5440/samsung: Staticize pcfgs
On Tue, Nov 27, 2012 at 3:49 PM, Axel Lin wrote: > I got below build error with random config if CONFIG_PINCTRL_SAMSUNG=y && > CONFIG_PINCTRL_EXYNOS5440=y. > > Fix the build error by making pcfgs static. > > LD drivers/pinctrl/built-in.o > drivers/pinctrl/pinctrl-exynos5440.o: In function `.LANCHOR0': > pinctrl-exynos5440.c:(.data+0x54): multiple definition of `pcfgs' > drivers/pinctrl/pinctrl-samsung.o:pinctrl-samsung.c:(.data+0x54): first > defined here > make[2]: *** [drivers/pinctrl/built-in.o] Error 1 > make[1]: *** [drivers/pinctrl] Error 2 > make: *** [drivers] Error 2 > > Signed-off-by: Axel Lin I'm not handling the Samsung drivers for this merge window. Samsung guys, can you please pick up this patch? Acked-by: Linus Walleij Yours, Linus Walleij -- 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: Likely mem leak in 3.7
I've extensively tested 2844a48706e5 (tip at the time I compiled) for the last few days and have been unable to reproduce. This bug appears to be fixed. Thanks. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4 v6] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
Varun Sethi wrote: > Following is a brief description of the PAMU hardware: > PAMU determines what action to take and whether to authorize the action on > the basis of the memory address, a Logical IO Device Number (LIODN), and > PAACT table (logically) indexed by LIODN and address. Hardware devices which > need to access memory must provide an LIODN in addition to the memory address. > > Peripheral Access Authorization and Control Tables (PAACTs) are the primary > data structures used by PAMU. A PAACT is a table of peripheral access > authorization and control entries (PAACE).Each PAACE defines the range of > I/O bus address space that is accessible by the LIOD and the associated access > capabilities. > > There are two types of PAACTs: primary PAACT (PPAACT) and secondary PAACT > (SPAACT).A given physical I/O device may be able to act as one or more > independent logical I/O devices (LIODs). Each such logical I/O device is > assigned an identifier called logical I/O device number (LIODN). A LIODN is > allocated a contiguous portion of the I/O bus address space called the DSA > window > for performing DSA operations. The DSA window may optionally be divided into > multiple sub-windows, each of which may be used to map to a region in system > storage space. The first sub-window is referred to as the primary sub-window > and the remaining are called secondary sub-windows. > > This patch provides the PAMU driver (fsl_pamu.c) and the corresponding IOMMU > API implementation (fsl_pamu_domain.c). The PAMU hardware driver (fsl_pamu.c) > has been derived from the work done by Ashish Kalra and Timur Tabi > (ti...@freescale.com). > > Signed-off-by: Timur Tabi > Signed-off-by: Varun Sethi > --- Acked-by: Timur Tabi -- Timur Tabi Linux kernel developer at Freescale -- 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 v2 1/8] video: tegra: Add nvhost driver
On Sun, Dec 02, 2012 at 07:42:06AM +1000, Dave Airlie wrote: > Guys I think you guys might be overthniking things here. > > I know you have some sort of upstream/downstream split, but really in > the upstream kernel, we don't care about that, so don't make it our > problem. > > There is no need for any sort of stable API between host1x and the sub > drivers, we change APIs in the kernel the whole time it isn't a > problem. Point taken. I was primarily concerned about needless churn during early development. But given the latest discussions it has become clear that there's no need to rush things and therefore we should be able to resolve any potential issues that could result in churn before the first patches are merged. > You can put the code where you want, maybe just under drivers/gpu > instead of drivers/video or drivers/gpu/drm, just make sure you have a > path for it into the kernel. drivers/gpu/host1x sounds like a good location to me. Does that still go in via your tree? Thierry pgpKEpwOAqOkn.pgp Description: PGP signature
Re: My SD Card Reader cannot read SDHC cards
On 12/01/2012 01:30 PM, Roger Heflin wrote: > On Sat, Dec 1, 2012 at 6:04 AM, Richard Yao wrote: >> Standard Microsystems Corp. 8-in-1 Card >> Reader > > Does that card reader support SDHC cards?The older readers don't > support >2GB (ie sdhc) > cards, and that would mean a 2GB card works and the 4GB or larger ones won't. SDHC is defined in version 2.0 of the Secure Digital specification, which did not exist when this card reader was made. From what I have read, the main difference aside from additional space is a change in the format of the Card-Specific Data register. Newer SD Card readers have no problem handling both formats and I expect that it is possible to modify older SD Card Readers to support it. I am not familiar with the subsystem involved, so I need some pointers before I can start looking at it. signature.asc Description: OpenPGP digital signature
Re: High context switch rate, ksoftirqd's chewing cpu
On 01.12.2012 20:13, Tejun Heo wrote: Hello, On Sat, Dec 01, 2012 at 06:11:10PM +0100, Zlatko Calusic wrote: Sure. Please clarify, should I apply it on top of the previous one or standalone? It's a replacement, so by itself. Thanks! I have good news, again. The kernel with the patch applied has been running flawlessly for the last hour. No excess context switching. Regards, -- Zlatko -- 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 GIT PULL] scheduler fix for autogroups
On Sat, Dec 1, 2012 at 1:44 PM, Ingo Molnar wrote: > > You are not missing anything. That flag is my fault not Mike's: > I booted the initial version of that patch but was unsure > whether autogroups was enabled - it's a pretty transparent > feature. So I figured that having that flag (but readonly) would > give us this information definitely. So what's the advantage of it being read-only at all? Since the flag is clearly *used*, make it read-write, and then all my objections go away (except for a slight worry that the dropping of /proc//autogroup_nice or whatever it is could break some odd system app, but I don't worry *too* much about that). Disabling autogroup is clearly something people might want, since the code tests for it. So removing the flag entirely seems wrong too. But if it exists, it should be writable. No? Linus -- 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: ACPI errors with 3.7-rc3
Update: laptop don't resume working not only after a long time held in suspend, but also after a short period of time for example 3 minutes. As for a long time - it about 24-36 hours. On Sun, Dec 2, 2012 at 12:59 AM, Azat Khuzhin wrote: > I tried this patch - https://bugzilla.kernel.org/attachment.cgi?id=73510 > from https://bugzilla.kernel.org/show_bug.cgi?id=14733. > > And I don't see such messages any more. > But another problem surfaced - laptop can't resume working after a > long time held in suspend, > end there is not messages in kern.log about that laptop trying to resume. > > On Sat, Nov 17, 2012 at 9:40 AM, Robert Hancock wrote: >> On 11/09/2012 10:36 AM, Feng Tang wrote: >>> >>> On Fri, Nov 09, 2012 at 10:30:43PM +0800, Moore, Robert wrote: The ACPI Global Lock is in fact intended to provide exclusion between the BIOS and the OS. Bob >>> >>> >>> Thanks for the info. >>> >>> And per my check, most of ACPI FW don't implement this lock, say >>> after driver probe, the ec->global_lock will be 0. >> >> >> The DSDT is supposed to define the _GLK control method on the EC if the BIOS >> needs to perform its own access which may conflict with the OS usage. If it >> doesn't, then it should be the case that either the BIOS doesn't touch the >> EC itself or it uses a separate interface that doesn't cause conflicts with >> what the OS is doing. >> >>> >>> - Feng >>> > -Original Message- > From: Tang, Feng > Sent: Friday, November 09, 2012 1:29 AM > To: Rafael J. Wysocki > Cc: Greg KH; Azat Khuzhin; linux-a...@vger.kernel.org; Linux Kernel > Mailing List; Zheng, Lv; Len Brown; Moore, Robert > Subject: Re: ACPI errors with 3.7-rc3 > > On Thu, Nov 08, 2012 at 05:49:40AM +0800, Rafael J. Wysocki wrote: >> >> On Tuesday, November 06, 2012 01:48:26 PM Greg KH wrote: >>> >>> On Tue, Nov 06, 2012 at 04:42:24PM +0400, Azat Khuzhin wrote: I'v also have such errors on my macbook pro. $ dmesg | tail [17056.008564] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88026547ea10), AE_TIME (20120711/psparse-536) [17056.011194] ACPI Error: Method parse/execution failed [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME (20120711/psparse-536) [17056.013793] ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME (20120711/psparse-536) [17056.016383] ACPI Exception: AE_TIME, Evaluating _BST (20120711/battery-464) [17056.511373] ACPI: EC: input buffer is not empty, aborting transaction [17056.512672] ACPI Exception: AE_TIME, Returned by Handler for [EmbeddedControl] (20120711/evregion-501) [17056.515256] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88026547ea10), AE_TIME (20120711/psparse-536) [17056.517886] ACPI Error: Method parse/execution failed [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME (20120711/psparse-536) [17056.520479] ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME (20120711/psparse-536) [17056.523070] ACPI Exception: AE_TIME, Evaluating _BST (20120711/battery-464) >>> >>> >>> I'm seeing this again right now. I'm wondering if it's because I'm >>> running on battery power at the moment: >>> >>> [41694.309264] ACPI Exception: AE_TIME, Returned by Handler for >>> [EmbeddedControl] (20120913/evregion-501) [41694.309282] ACPI Error: >>> Method parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node >>> 88045cc64618), AE_TIME (20120913/psparse-536) [41694.309300] >>> ACPI Error: Method parse/execution failed [\_SB_.BAT0.UBST] (Node >>> 88045cc64988), AE_TIME (20120913/psparse-536) [41694.309310] >>> ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] (Node >>> 88045cc648c0), AE_TIME (20120913/psparse-536) [41694.309324] >>> ACPI Exception: AE_TIME, Evaluating _BST (20120913/battery-464) >>> [41694.809093] ACPI: EC: input buffer is not empty, aborting >>> transaction >>> >>> ec_storm_threshold is still set to 8 in /sys/module/acpi/parameters/ >>> so that's not the issue here. >>> And also loadavg is too high ~ 10 While there is no process that load CPU up to 100% or like that. I think that this because of processes that is done in kernel space. (basically that one who write such errors) $ uname -a Linux macbook-pro-sq 3.6.5macbook-pro-custom-v0.1 #4 SMP Sun Nov 4 12:39:03 UTC 2012 x86_64 GNU/Linux >>> >>> >>> Ah, ok, that means it's not something new in 3.7-rc, so maybe it's >>> just never worked properly for this
Re: [RFC GIT PULL] scheduler fix for autogroups
* Ingo Molnar wrote: > You are not missing anything. That flag is my fault not > Mike's: I booted the initial version of that patch but was > unsure whether autogroups was enabled - it's a pretty > transparent feature. So I figured that having that flag (but > readonly) would give us this information definitely. The other reason was that the original version of the patch also added a boot parameter - to enable/disable autogroups from the boot command line. With *that* configuration twist it made sense to present this information somewhere in /proc as well. But then we got rid of the boot parameter to simplify the patch - which further reduced the sense of the /proc/sys/kernel/sched_autogroup_enabled flag - which now can only ever be 1. Thanks, Ingo -- 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 GIT PULL] scheduler fix for autogroups
* Linus Torvalds wrote: > On Sat, Dec 1, 2012 at 3:16 AM, Ingo Molnar wrote: > > > > Please [RFC] pull the latest sched-urgent-for-linus git tree > > from: > > No. That patch is braindead. I wouldn't pull it even if it > wasn't this late. > > Why the hell leave a read-only 'sched_autogroup_enabled' proc > file? > > What the f*ck is the point? It looks like the flag still > exists (we test it), but now there's no point to it, since you > can't change it. > > What am I missing? You are not missing anything. That flag is my fault not Mike's: I booted the initial version of that patch but was unsure whether autogroups was enabled - it's a pretty transparent feature. So I figured that having that flag (but readonly) would give us this information definitely. So I suggested to Mike to keep that flag so that user-space is informed that autogroups is enabled. It seemed like a cute usability twist at that time, and there's existing precedent for it in /proc, but now I'm not so sure anymore... Should we use some other file for that - or no file at all and just emit a bootup printk for kernel hackers with a short attention span? Thanks, Ingo -- 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 v2 1/8] video: tegra: Add nvhost driver
Guys I think you guys might be overthniking things here. I know you have some sort of upstream/downstream split, but really in the upstream kernel, we don't care about that, so don't make it our problem. There is no need for any sort of stable API between host1x and the sub drivers, we change APIs in the kernel the whole time it isn't a problem. If you need to change the API, submit a single patch changing it across all the drivers in the tree, collecting Acks or not as needed. We do this the whole time, I've never had or seen a problem with it. We don't do separate subsystems APIs set in stone bullshit, and all subsystem maintainers are used to dealing with these sort of issues. You get an ack from one maintainer and the other one sticks it in his tree with a note to Linus. You can put the code where you want, maybe just under drivers/gpu instead of drivers/video or drivers/gpu/drm, just make sure you have a path for it into the kernel. And I have an non-upstream precedent for v4l sitting on drm, some radeon GPUs have capture tuners, and the only way to implement that would be to stick a v4l driver in the radeon drm driver. Not a problem, just never finished writing the code. Dave. -- 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: Regression with initramfs and nfsroot (appears to be in the dcache)
On Fri, Nov 30, 2012 at 01:58:18PM +, Myklebust, Trond wrote:
> The reason for the choice of d_drop over d_invalidate() is the d_count
> checks. It really doesn't matter whether or not the client thinks it has
> users for a directory if the server is telling you that it is ESTALE. So
> we force a d_drop to prevent further lookups from finding it.
>
> IOW: It is there in order to fix the case where the user does
> 'rmdir("foo"); mkdir("foo")' on the server.
You do realize that your have_submounts() check in there is inherently
racy, right?
--
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 GIT PULL] scheduler fix for autogroups
On Sat, Dec 1, 2012 at 3:16 AM, Ingo Molnar wrote: > > Please [RFC] pull the latest sched-urgent-for-linus git tree > from: No. That patch is braindead. I wouldn't pull it even if it wasn't this late. Why the hell leave a read-only 'sched_autogroup_enabled' proc file? What the f*ck is the point? It looks like the flag still exists (we test it), but now there's no point to it, since you can't change it. What am I missing? Linus -- 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: ACPI errors with 3.7-rc3
I tried this patch - https://bugzilla.kernel.org/attachment.cgi?id=73510 from https://bugzilla.kernel.org/show_bug.cgi?id=14733. And I don't see such messages any more. But another problem surfaced - laptop can't resume working after a long time held in suspend, end there is not messages in kern.log about that laptop trying to resume. On Sat, Nov 17, 2012 at 9:40 AM, Robert Hancock wrote: > On 11/09/2012 10:36 AM, Feng Tang wrote: >> >> On Fri, Nov 09, 2012 at 10:30:43PM +0800, Moore, Robert wrote: >>> >>> The ACPI Global Lock is in fact intended to provide exclusion between the >>> BIOS and the OS. >>> Bob >> >> >> Thanks for the info. >> >> And per my check, most of ACPI FW don't implement this lock, say >> after driver probe, the ec->global_lock will be 0. > > > The DSDT is supposed to define the _GLK control method on the EC if the BIOS > needs to perform its own access which may conflict with the OS usage. If it > doesn't, then it should be the case that either the BIOS doesn't touch the > EC itself or it uses a separate interface that doesn't cause conflicts with > what the OS is doing. > >> >> - Feng >> >>> >>> -Original Message- From: Tang, Feng Sent: Friday, November 09, 2012 1:29 AM To: Rafael J. Wysocki Cc: Greg KH; Azat Khuzhin; linux-a...@vger.kernel.org; Linux Kernel Mailing List; Zheng, Lv; Len Brown; Moore, Robert Subject: Re: ACPI errors with 3.7-rc3 On Thu, Nov 08, 2012 at 05:49:40AM +0800, Rafael J. Wysocki wrote: > > On Tuesday, November 06, 2012 01:48:26 PM Greg KH wrote: >> >> On Tue, Nov 06, 2012 at 04:42:24PM +0400, Azat Khuzhin wrote: >>> >>> I'v also have such errors on my macbook pro. >>> >>> $ dmesg | tail >>> [17056.008564] ACPI Error: Method parse/execution failed >>> [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88026547ea10), AE_TIME >>> (20120711/psparse-536) >>> [17056.011194] ACPI Error: Method parse/execution failed >>> [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME >>> (20120711/psparse-536) >>> [17056.013793] ACPI Error: Method parse/execution failed >>> [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME >>> (20120711/psparse-536) >>> [17056.016383] ACPI Exception: AE_TIME, Evaluating _BST >>> (20120711/battery-464) [17056.511373] ACPI: EC: input buffer is >>> not empty, aborting transaction [17056.512672] ACPI Exception: >>> AE_TIME, Returned by Handler for [EmbeddedControl] >>> (20120711/evregion-501) [17056.515256] ACPI Error: Method >>> parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node >>> 88026547ea10), AE_TIME >>> (20120711/psparse-536) >>> [17056.517886] ACPI Error: Method parse/execution failed >>> [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME >>> (20120711/psparse-536) >>> [17056.520479] ACPI Error: Method parse/execution failed >>> [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME >>> (20120711/psparse-536) >>> [17056.523070] ACPI Exception: AE_TIME, Evaluating _BST >>> (20120711/battery-464) >> >> >> I'm seeing this again right now. I'm wondering if it's because I'm >> running on battery power at the moment: >> >> [41694.309264] ACPI Exception: AE_TIME, Returned by Handler for >> [EmbeddedControl] (20120913/evregion-501) [41694.309282] ACPI Error: >> Method parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node >> 88045cc64618), AE_TIME (20120913/psparse-536) [41694.309300] >> ACPI Error: Method parse/execution failed [\_SB_.BAT0.UBST] (Node >> 88045cc64988), AE_TIME (20120913/psparse-536) [41694.309310] >> ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] (Node >> 88045cc648c0), AE_TIME (20120913/psparse-536) [41694.309324] >> ACPI Exception: AE_TIME, Evaluating _BST (20120913/battery-464) >> [41694.809093] ACPI: EC: input buffer is not empty, aborting >> transaction >> >> ec_storm_threshold is still set to 8 in /sys/module/acpi/parameters/ >> so that's not the issue here. >> >>> And also loadavg is too high ~ 10 >>> While there is no process that load CPU up to 100% or like that. >>> I think that this because of processes that is done in kernel space. >>> (basically that one who write such errors) >>> >>> $ uname -a >>> Linux macbook-pro-sq 3.6.5macbook-pro-custom-v0.1 #4 SMP Sun Nov 4 >>> 12:39:03 UTC 2012 x86_64 GNU/Linux >> >> >> Ah, ok, that means it's not something new in 3.7-rc, so maybe it's >> just never worked properly for this hardware :) >> >> So it's not a regression, just an ACPI issue, any ACPI developer >> have an idea about this? > > > Can you please send the output of acpidump from the affected > machine(s)? I doubt this problem is sometimes inevitable for some machines, because AFAIK most modern machines have the race problem
[PATCH RESEND] ds1374: add support of device tree
Signed-off-by: Philippe Reynes
---
drivers/rtc/rtc-ds1374.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/rtc/rtc-ds1374.c b/drivers/rtc/rtc-ds1374.c
index 9663160..174c532 100644
--- a/drivers/rtc/rtc-ds1374.c
+++ b/drivers/rtc/rtc-ds1374.c
@@ -49,6 +49,14 @@ static const struct i2c_device_id ds1374_id[] = {
};
MODULE_DEVICE_TABLE(i2c, ds1374_id);
+#ifdef CONFIG_OF
+static const struct of_device_id ds1374_of_match[] __devinitconst = {
+ { .compatible = "dallas,ds1374" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, ds1374_of_match);
+#endif
+
struct ds1374 {
struct i2c_client *client;
struct rtc_device *rtc;
--
1.7.4.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 2/2] New driver: Xillybus generic interface for FPGA (programmable logic)
On Saturday 01 December 2012, Philip Balister wrote: > On 11/30/2012 09:36 AM, Greg KH wrote: > > Yes, I know of at least one more device other than the ones listed above > > that wants this type of functionality as well, so defining it in a > > standard user/kernel api manner would be very good to do. > > I'm concerned that a standard driver for FPGA's will be a very difficult > problem. > > The Xillybus driver looks interesting on several levels, however my > first concern is depends on a FPGA IP block that is not open source. > This is not a bad thing, just a potential obstacle for some people. I agree that is a concern, but for now, I'm mostly worried about the kernel-to-user interface. If we can agree on a driver interface that works for Xillybus as well as any of the others we know about, we can start using that as the generic kernel FPGA interface. Once we get a second FPGA driver, that can use the same user interface but talk to the hardware in a different way, and then we can reorganise the code to keep the user interface bits in a common driver, away from the hardware specific parts. If you see anything in the user interface that directly depends on the Xillybus IP block, then that would make the approach impossible and we should change that to be more generic. > I've been engaged in design discussions today with my customer. Our > target is the Xilinx Zynq hardware. The first pass at a driver focuses > on creating the minimal amount of code in the kernel doing most of the > logic in user space. So the driver code allocates a large chunk of RAM > for the FPGA to read/write to, provides a mmap function so user space > can see this RAM, also mmaps in the address space of an AXI slave so the > user space can control the logic. This approach has no dependencies on > what is loaded into the fpga. > > This is a very different approach then the Xillybus driver, but should > also be useful to a large class of people. Hopefully, we can converge on > a set of useful drivers, and not end up with a million drivers all based > on custom fpga configuration :) Agreed. If I understand you correctly though, your approach is specific to a particular hardware implementation (Zynq) on the user interface layer, which I think is exactly what we should avoid. Obviously, there is always a driver involved that is specific to the IP block you load into an FPGA at runtime, and that is ok. The two parts that I think we should agree on are: a) How to get a payload into the FPGA b) How to find a device driver that can make the payload interface to user space. Arnd -- 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] net: phy: smsc: force all capable mode if the phy is started in powerdown mode
A SMSC PHY in power down mode can't be used.
If a SMSC PHY is in this mode in the config_init
stage, the mode "all capable" is set. So the PHY
could then be used.
Signed-off-by: Philippe Reynes
---
drivers/net/phy/smsc.c | 27 ++-
include/linux/smscphy.h |5 +
2 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c
index 88e3991..63018d0 100644
--- a/drivers/net/phy/smsc.c
+++ b/drivers/net/phy/smsc.c
@@ -43,7 +43,32 @@ static int smsc_phy_ack_interrupt(struct phy_device *phydev)
static int smsc_phy_config_init(struct phy_device *phydev)
{
- int rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
+ /*
+* If the SMSC PHY is in power down mode, then set it
+* in all capable mode before using it.
+*/
+ int rc = phy_read(phydev, MII_LAN83C185_SPECIAL_MODES);
+ if (rc < 0)
+ return rc;
+
+ if ((rc & MII_LAN83C185_MODE_MASK) == MII_LAN83C185_MODE_POWERDOWN) {
+ int timeout = 5;
+
+ /* set "all capable" mode and reset the phy */
+ rc |= MII_LAN83C185_MODE_ALL;
+ phy_write(phydev, MII_LAN83C185_SPECIAL_MODES, rc);
+ phy_write(phydev, MII_BMCR, BMCR_RESET);
+
+ /* wait end of reset (max 500 ms) */
+ do {
+ udelay(10);
+ if (timeout-- == 0)
+ return -1;
+ rc = phy_read(phydev, MII_BMCR);
+ } while (rc & BMCR_RESET);
+ }
+
+ rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
if (rc < 0)
return rc;
diff --git a/include/linux/smscphy.h b/include/linux/smscphy.h
index ce718cb..f4bf16e 100644
--- a/include/linux/smscphy.h
+++ b/include/linux/smscphy.h
@@ -4,6 +4,7 @@
#define MII_LAN83C185_ISF 29 /* Interrupt Source Flags */
#define MII_LAN83C185_IM 30 /* Interrupt Mask */
#define MII_LAN83C185_CTRL_STATUS 17 /* Mode/Status Register */
+#define MII_LAN83C185_SPECIAL_MODES 18 /* Special Modes Register */
#define MII_LAN83C185_ISF_INT1 (1<<1) /* Auto-Negotiation Page Received */
#define MII_LAN83C185_ISF_INT2 (1<<2) /* Parallel Detection Fault */
@@ -22,4 +23,8 @@
#define MII_LAN83C185_EDPWRDOWN (1 << 13) /* EDPWRDOWN */
#define MII_LAN83C185_ENERGYON (1 << 1) /* ENERGYON */
+#define MII_LAN83C185_MODE_MASK 0xE0
+#define MII_LAN83C185_MODE_POWERDOWN 0xC0 /* Power Down mode */
+#define MII_LAN83C185_MODE_ALL 0xE0 /* All capable mode */
+
#endif /* __LINUX_SMSCPHY_H__ */
--
1.7.4.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/
blk: bd_block_size_semaphore related lockdep warning
Hi all,
While fuzzing with trinity inside a KVM tools guest, running latest -next, I've
stumbled on:
[ 3130.099477] ==
[ 3130.104862] [ INFO: possible circular locking dependency detected ]
[ 3130.104862] 3.7.0-rc7-next-20121130-sasha-00015-g06fcc7a-dirty #2 Tainted: G
W
[ 3130.104862] ---
[ 3130.104862] trinity-child77/12730 is trying to acquire lock:
[ 3130.104862] (>s_type->i_mutex_key#17/1){+.+.+.}, at:
[] pipe_lock_nested.isra.2+0x15/0x20
[ 3130.104862]
[ 3130.104862] but task is already holding lock:
[ 3130.104862] (sb_writers#16){.+.+..}, at: []
generic_file_splice_write+0x6f/0x170
[ 3130.104862]
[ 3130.104862] which lock already depends on the new lock.
[ 3130.104862]
[ 3130.104862]
[ 3130.104862] the existing dependency chain (in reverse order) is:
[ 3130.104862]
-> #3 (sb_writers#16){.+.+..}:
[ 3130.104862][] lock_acquire+0x1aa/0x240
[ 3130.104862][] __sb_start_write+0x146/0x1b0
[ 3130.104862][] generic_file_splice_write+0x6f/0x170
[ 3130.104862][] blkdev_splice_write+0x5a/0x80
[ 3130.104862][] do_splice_from+0x83/0xb0
[ 3130.104862][] sys_splice+0x492/0x690
[ 3130.104862][] tracesys+0xe1/0xe6
[ 3130.104862]
-> #2 (>bdev.bd_block_size_semaphore){.+}:
[ 3130.104862][] lock_acquire+0x1aa/0x240
[ 3130.104862][] percpu_down_read+0x55/0x90
[ 3130.104862][] blkdev_mmap+0x33/0x60
[ 3130.104862][] mmap_region+0x31b/0x600
[ 3130.104862][] do_mmap_pgoff+0x2b7/0x330
[ 3130.104862][] vm_mmap_pgoff+0x7a/0xa0
[ 3130.104862][] sys_mmap_pgoff+0x16e/0x1b0
[ 3130.104862][] sys_mmap+0x1d/0x20
[ 3130.104862][] tracesys+0xe1/0xe6
[ 3130.104862]
-> #1 (>mmap_sem){++}:
[ 3130.104862][] lock_acquire+0x1aa/0x240
[ 3130.104862][] might_fault+0x7b/0xa0
[ 3130.104862][] sys_vmsplice+0xd5/0x220
[ 3130.104862][] tracesys+0xe1/0xe6
[ 3130.104862]
-> #0 (>s_type->i_mutex_key#17/1){+.+.+.}:
[ 3130.104862][] __lock_acquire+0x147f/0x1c30
[ 3130.104862][] lock_acquire+0x1aa/0x240
[ 3130.104862][] __mutex_lock_common+0x59/0x5a0
[ 3130.104862][] mutex_lock_nested+0x3f/0x50
[ 3130.104862][] pipe_lock_nested.isra.2+0x15/0x20
[ 3130.104862][] pipe_lock+0x15/0x20
[ 3130.104862][] generic_file_splice_write+0x77/0x170
[ 3130.104862][] blkdev_splice_write+0x5a/0x80
[ 3130.104862][] do_splice_from+0x83/0xb0
[ 3130.104862][] sys_splice+0x492/0x690
[ 3130.104862][] tracesys+0xe1/0xe6
[ 3130.104862]
[ 3130.104862] other info that might help us debug this:
[ 3130.104862]
[ 3130.104862] Chain exists of:
>s_type->i_mutex_key#17/1 --> >bdev.bd_block_size_semaphore -->
sb_writers#16
[ 3130.104862] Possible unsafe locking scenario:
[ 3130.104862]
[ 3130.104862]CPU0CPU1
[ 3130.104862]
[ 3130.104862] lock(sb_writers#16);
[ 3130.104862]
lock(>bdev.bd_block_size_semaphore);
[ 3130.104862]lock(sb_writers#16);
[ 3130.104862] lock(>s_type->i_mutex_key#17/1);
[ 3130.104862]
[ 3130.104862] *** DEADLOCK ***
[ 3130.104862]
[ 3130.104862] 2 locks held by trinity-child77/12730:
[ 3130.104862] #0: (>bdev.bd_block_size_semaphore){.+}, at:
[] blkdev_splice_write+0x45/0x80
[ 3130.104862] #1: (sb_writers#16){.+.+..}, at: []
generic_file_splice_write+0x6f/0x170
[ 3130.104862]
[ 3130.104862] stack backtrace:
[ 3130.104862] Pid: 12730, comm: trinity-child77 Tainted: GW
3.7.0-rc7-next-20121130-sasha-00015-g06fcc7a-dirty #2
[ 3130.104862] Call Trace:
[ 3130.104862] [] print_circular_bug+0x1fb/0x20c
[ 3130.104862] [] __lock_acquire+0x147f/0x1c30
[ 3130.104862] [] lock_acquire+0x1aa/0x240
[ 3130.104862] [] ? pipe_lock_nested.isra.2+0x15/0x20
[ 3130.104862] [] __mutex_lock_common+0x59/0x5a0
[ 3130.104862] [] ? pipe_lock_nested.isra.2+0x15/0x20
[ 3130.104862] [] ? __lock_is_held+0x5a/0x80
[ 3130.104862] [] ? pipe_lock_nested.isra.2+0x15/0x20
[ 3130.104862] [] mutex_lock_nested+0x3f/0x50
[ 3130.104862] [] pipe_lock_nested.isra.2+0x15/0x20
[ 3130.104862] [] pipe_lock+0x15/0x20
[ 3130.104862] [] generic_file_splice_write+0x77/0x170
[ 3130.104862] [] blkdev_splice_write+0x5a/0x80
[ 3130.104862] [] do_splice_from+0x83/0xb0
[ 3130.104862] [] sys_splice+0x492/0x690
[ 3130.104862] [] ? syscall_trace_enter+0x20/0x2e0
[ 3130.104862] [] tracesys+0xe1/0xe6
Thanks,
sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] mm/migration: Make rmap_walk_anon() and try_to_unmap_anon() more scalable
On 12/01/2012 03:15 PM, Ingo Molnar wrote:
Index: linux/include/linux/rmap.h
===
--- linux.orig/include/linux/rmap.h
+++ linux/include/linux/rmap.h
@@ -128,6 +128,17 @@ static inline void anon_vma_unlock(struc
up_write(_vma->root->rwsem);
}
+static inline void anon_vma_lock_read(struct anon_vma *anon_vma)
+{
+ down_read(_vma->root->rwsem);
+}
I see you did not rename anon_vma_lock and anon_vma_unlock
to anon_vma_lock_write and anon_vma_unlock_write.
That could get confusing to people touching that code in
the future.
The patch looks correct, though.
--
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] New driver: Xillybus generic interface for FPGA (programmable logic)
On Sat, Dec 01, 2012 at 11:30:55AM -0800, Philip Balister wrote: > On 12/01/2012 08:56 AM, Greg KH wrote: > >On Fri, Nov 30, 2012 at 07:19:16PM -0800, Philip Balister wrote: [..] > > > >>I've been engaged in design discussions today with my customer. Our > >>target is the Xilinx Zynq hardware. The first pass at a driver > >>focuses on creating the minimal amount of code in the kernel doing > >>most of the logic in user space. So the driver code allocates a > >>large chunk of RAM for the FPGA to read/write to, provides a mmap > >>function so user space can see this RAM, also mmaps in the address > >>space of an AXI slave so the user space can control the logic. This > >>approach has no dependencies on what is loaded into the fpga. > > > >Would a simple UIO driver work best for this type of arrangement? Then > >those types of hardware wouldn't even need to mess with a fpga-type > >interface. > > It is very close to a UIO approach. My key problem I am trying to solve is > getting a "large" buffer space for the driver and a way to communicate the > physical address and size of the buffer to the fpga. The fpga has several > ports that allow it to directly read/write RAM, but it needs to know > physical addresses. > > >>This is a very different approach then the Xillybus driver, but > >>should also be useful to a large class of people. Hopefully, we can > >>converge on a set of useful drivers, and not end up with a million > >>drivers all based on custom fpga configuration :) > > > >Odds are, this should look something like the firmware interface in the > >end, right? Userspace dumps a bunch of data to the device, and then > >needs the driver to toggle some bits somewhere to enable the device. > >Also, a few control calls like clearing the device, and other minor > >things should be all that is needed, right? > > > > For zynq, there is an out of tree ( :) ) driver that handles the firmware > loading. This is an independent problem. > > >So, in the grand tradition of, "The first one there wins", why not base > >it all off of your driver, and how that works, and we can go from there :) > > I do not think there will be any one driver that will work for all use cases > due to the variety of devices that can be implemented in the fpga. I see this working such that each IP block/independent logic unit in the FPGA bitfile would be reified as an independent device to the kernel, perhaps as a child of an 'fpga' bus (or similar). These devices would have their own drivers, and would come and go as the logic is reprogrammed. This is really useful if you're taking and integrating IP that exposes a known interface with existing in-kernel Linux drivers. Think a soft Ethernet MAC IP or a 16550 or something. For more application specific things, or lower level/less defined IO like you described, an instance of a UIO driver might fit well. (Anything more complicated then simple register accesses or interrupts might require something more.) The key point here is that there is a need for a common reprogrammable logic subsystem that provides an abstraction over the various reprogrammable logic devices and exposes a common user interfaces for download and configuration. This user interface would need to encompass a way to hand the kernel a blob and a description of the IP contained within. Grant's recent dynamic device tree work seems like would be a great fit for this (and infact, I believe this use case was explicitly listed as a userstory). Josh pgpQxwjRuGPUh.pgp Description: PGP signature
Re: 3.7-rc7: BUG: MAX_STACK_TRACE_ENTRIES too low!
On Wed, 28 Nov 2012 at 16:41, Li Zhong wrote: > On Tue, 2012-11-27 at 19:22 -0800, Christian Kujau wrote: > > On Tue, 27 Nov 2012 at 19:06, Christian Kujau wrote: > > > the same thing[0] happened again in 3.7-rc7, after ~20h uptime: > > > > I found the following on patchwork, but this seems to deal with powerpc64 > > only, while this PowerBook G4 of mine is powerpc32: > > > > http://patchwork.ozlabs.org/patch/193414/ > > > > It looks related, but then again, I fail to parse assember... > > Hi Christian, > > Would you please help to try the following fix? I don't have a powerpc32 > machine for test... After 3 days of uptime with your patch applied (and "normal" usage, just as before) no such BUG message occured. So, from my point of view, feel free to add: Tested-by: Christian Kujau Thanks! Christian. > == > diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S > index 9499385..cadebfd 100644 > --- a/arch/powerpc/kernel/entry_32.S > +++ b/arch/powerpc/kernel/entry_32.S > @@ -439,6 +439,8 @@ ret_from_fork: > ret_from_kernel_thread: > REST_NVGPRS(r1) > bl schedule_tail > + li r3,0 > + stw r3,0(r1) > mtlrr14 > mr r3,r15 > PPC440EP_ERR42 > == > > > > > Christian. > > > > > [40007.339487] [sched_delayed] sched: RT throttling activated > > > [69731.388717] BUG: MAX_STACK_TRACE_ENTRIES too low! > > > [69731.390371] turning off the locking correctness validator. > > > [69731.391942] Call Trace: > > > [69731.393525] [c9a61c10] [c0009064] show_stack+0x70/0x1bc (unreliable) > > > [69731.395152] [c9a61c50] [c0077460] save_trace+0xfc/0x114 > > > [69731.396735] [c9a61c60] [c007be20] __lock_acquire+0x1568/0x19b8 > > > [69731.398296] [c9a61d00] [c007c2c0] lock_acquire+0x50/0x70 > > > [69731.399857] [c9a61d20] [c0550e28] _raw_spin_lock_irq+0x5c/0x78 > > > [69731.401419] [c9a61d40] [c054fb58] __schedule+0xd8/0x534 > > > [69731.402972] [c9a61da0] [c0550094] _cond_resched+0x50/0x68 > > > [69731.404527] [c9a61db0] [c0479908] dst_gc_task+0xbc/0x258 > > > [69731.406070] [c9a61e40] [c004eeb8] process_one_work+0x1f4/0x49c > > > [69731.407585] [c9a61e80] [c004f644] worker_thread+0x14c/0x400 > > > [69731.409075] [c9a61eb0] [c0057634] kthread+0xbc/0xc0 > > > [69731.410521] [c9a61f40] [c0011ad4] ret_from_kernel_thread+0x5c/0x64 > > > [...repeated 54 times...] > > > > > > Anyone knows what this is about? > > > > > > Thanks, > > > Christian. > > > > > > [0] http://lkml.indiana.edu/hypermail/linux/kernel/1211.0/03025.html -- BOFH excuse #267: The UPS is on strike. -- 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] mm/rmap: Convert the struct anon_vma::mutex to an rwsem
On 12/01/2012 03:10 PM, Ingo Molnar wrote: Convert the struct anon_vma::mutex to an rwsem, which will help in solving a page-migration scalability problem. (Addressed in a separate patch.) The conversion is simple and straightforward: in every case where we mutex_lock()ed we'll now down_write(). Suggested-by: Linus Torvalds Cc: Andrew Morton Cc: Peter Zijlstra Cc: Andrea Arcangeli Cc: Rik van Riel Cc: Mel Gorman Cc: Hugh Dickins Signed-off-by: Ingo Molnar Reviewed-by: Rik van Riel -- All rights reversed -- 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] mm/migration: Make rmap_walk_anon() and try_to_unmap_anon() more scalable
Note, with this optimization I went a farther than the
boundaries of the migration code - it seemed worthwile to do and
I've reviewed all the other users of page_lock_anon_vma() as
well and none seemed to be modifying the list inside that lock.
Please review this patch carefully - in particular the SMP races
outlined in anon_vma_free() are exciting: I have updated the
reasoning and it still appears to hold, but please double check
the changes nevertheless ...
Thanks,
Ingo
--->
From: Ingo Molnar
Date: Sat Dec 1 20:43:04 CET 2012
rmap_walk_anon() and try_to_unmap_anon() appears to be too careful
about locking the anon vma: while it needs protection against anon
vma list modifications, it does not need exclusive access to the
list itself.
Transforming this exclusive lock to a read-locked rwsem removes a
global lock from the hot path of page-migration intense threaded
workloads which can cause pathological performance like this:
96.43%process 0 [kernel.kallsyms] [k] perf_trace_sched_switch
|
--- perf_trace_sched_switch
__schedule
schedule
schedule_preempt_disabled
__mutex_lock_common.isra.6
__mutex_lock_slowpath
mutex_lock
|
|--50.61%-- rmap_walk
| move_to_new_page
| migrate_pages
| migrate_misplaced_page
| __do_numa_page.isra.69
| handle_pte_fault
| handle_mm_fault
| __do_page_fault
| do_page_fault
| page_fault
| __memset_sse2
| |
| --100.00%-- worker_thread
| |
| --100.00%-- start_thread
|
--49.39%-- page_lock_anon_vma
try_to_unmap_anon
try_to_unmap
migrate_pages
migrate_misplaced_page
__do_numa_page.isra.69
handle_pte_fault
handle_mm_fault
__do_page_fault
do_page_fault
page_fault
__memset_sse2
|
--100.00%-- worker_thread
start_thread
With this change applied the profile is now nicely flat
and there's no anon-vma related scheduling/blocking.
Cc: Linus Torvalds
Cc: Andrew Morton
Cc: Peter Zijlstra
Cc: Andrea Arcangeli
Cc: Rik van Riel
Cc: Mel Gorman
Cc: Hugh Dickins
Signed-off-by: Ingo Molnar
---
include/linux/rmap.h | 15 +--
mm/huge_memory.c |4 ++--
mm/memory-failure.c |4 ++--
mm/migrate.c |2 +-
mm/rmap.c| 40
5 files changed, 38 insertions(+), 27 deletions(-)
Index: linux/include/linux/rmap.h
===
--- linux.orig/include/linux/rmap.h
+++ linux/include/linux/rmap.h
@@ -128,6 +128,17 @@ static inline void anon_vma_unlock(struc
up_write(_vma->root->rwsem);
}
+static inline void anon_vma_lock_read(struct anon_vma *anon_vma)
+{
+ down_read(_vma->root->rwsem);
+}
+
+static inline void anon_vma_unlock_read(struct anon_vma *anon_vma)
+{
+ up_read(_vma->root->rwsem);
+}
+
+
/*
* anon_vma helper functions.
*/
@@ -220,8 +231,8 @@ int try_to_munlock(struct page *);
/*
* Called by memory-failure.c to kill processes.
*/
-struct anon_vma *page_lock_anon_vma(struct page *page);
-void page_unlock_anon_vma(struct anon_vma *anon_vma);
+struct anon_vma *page_lock_anon_vma_read(struct page *page);
+void page_unlock_anon_vma_read(struct anon_vma *anon_vma);
int page_mapped_in_vma(struct page *page, struct vm_area_struct *vma);
/*
Index: linux/mm/huge_memory.c
===
--- linux.orig/mm/huge_memory.c
+++ linux/mm/huge_memory.c
@@ -1645,7 +1645,7 @@ int split_huge_page(struct page *page)
int ret = 1;
BUG_ON(!PageAnon(page));
- anon_vma = page_lock_anon_vma(page);
+ anon_vma = page_lock_anon_vma_read(page);
if (!anon_vma)
goto out;
ret = 0;
@@ -1658,7 +1658,7 @@ int split_huge_page(struct page *page)
BUG_ON(PageCompound(page));
out_unlock:
- page_unlock_anon_vma(anon_vma);
+
[PATCH 1/2] mm/rmap: Convert the struct anon_vma::mutex to an rwsem
Convert the struct anon_vma::mutex to an rwsem, which will help
in solving a page-migration scalability problem. (Addressed in
a separate patch.)
The conversion is simple and straightforward: in every case
where we mutex_lock()ed we'll now down_write().
Suggested-by: Linus Torvalds
Cc: Andrew Morton
Cc: Peter Zijlstra
Cc: Andrea Arcangeli
Cc: Rik van Riel
Cc: Mel Gorman
Cc: Hugh Dickins
Signed-off-by: Ingo Molnar
---
include/linux/rmap.h | 16
mm/huge_memory.c |4 ++--
mm/mmap.c|8
mm/rmap.c| 22 +++---
4 files changed, 25 insertions(+), 25 deletions(-)
Index: linux/include/linux/rmap.h
===
--- linux.orig/include/linux/rmap.h
+++ linux/include/linux/rmap.h
@@ -7,7 +7,7 @@
#include
#include
#include
-#include
+#include
#include
/*
@@ -25,8 +25,8 @@
* pointing to this anon_vma once its vma list is empty.
*/
struct anon_vma {
- struct anon_vma *root; /* Root of this anon_vma tree */
- struct mutex mutex; /* Serialize access to vma list */
+ struct anon_vma *root; /* Root of this anon_vma tree */
+ struct rw_semaphore rwsem; /* W: modification, R: walking the list
*/
/*
* The refcount is taken on an anon_vma when there is no
* guarantee that the vma of page tables will exist for
@@ -64,7 +64,7 @@ struct anon_vma_chain {
struct vm_area_struct *vma;
struct anon_vma *anon_vma;
struct list_head same_vma; /* locked by mmap_sem & page_table_lock */
- struct rb_node rb; /* locked by anon_vma->mutex */
+ struct rb_node rb; /* locked by anon_vma->rwsem */
unsigned long rb_subtree_last;
#ifdef CONFIG_DEBUG_VM_RB
unsigned long cached_vma_start, cached_vma_last;
@@ -108,24 +108,24 @@ static inline void vma_lock_anon_vma(str
{
struct anon_vma *anon_vma = vma->anon_vma;
if (anon_vma)
- mutex_lock(_vma->root->mutex);
+ down_write(_vma->root->rwsem);
}
static inline void vma_unlock_anon_vma(struct vm_area_struct *vma)
{
struct anon_vma *anon_vma = vma->anon_vma;
if (anon_vma)
- mutex_unlock(_vma->root->mutex);
+ up_write(_vma->root->rwsem);
}
static inline void anon_vma_lock(struct anon_vma *anon_vma)
{
- mutex_lock(_vma->root->mutex);
+ down_write(_vma->root->rwsem);
}
static inline void anon_vma_unlock(struct anon_vma *anon_vma)
{
- mutex_unlock(_vma->root->mutex);
+ up_write(_vma->root->rwsem);
}
/*
Index: linux/mm/huge_memory.c
===
--- linux.orig/mm/huge_memory.c
+++ linux/mm/huge_memory.c
@@ -1388,7 +1388,7 @@ static int __split_huge_page_splitting(s
* We can't temporarily set the pmd to null in order
* to split it, the pmd must remain marked huge at all
* times or the VM won't take the pmd_trans_huge paths
-* and it won't wait on the anon_vma->root->mutex to
+* and it won't wait on the anon_vma->root->rwsem to
* serialize against split_huge_page*.
*/
pmdp_splitting_flush(vma, address, pmd);
@@ -1591,7 +1591,7 @@ static int __split_huge_page_map(struct
return ret;
}
-/* must be called with anon_vma->root->mutex hold */
+/* must be called with anon_vma->root->rwsem held */
static void __split_huge_page(struct page *page,
struct anon_vma *anon_vma)
{
Index: linux/mm/mmap.c
===
--- linux.orig/mm/mmap.c
+++ linux/mm/mmap.c
@@ -2561,15 +2561,15 @@ static void vm_lock_anon_vma(struct mm_s
* The LSB of head.next can't change from under us
* because we hold the mm_all_locks_mutex.
*/
- mutex_lock_nest_lock(_vma->root->mutex, >mmap_sem);
+ down_write(_vma->root->rwsem);
/*
* We can safely modify head.next after taking the
-* anon_vma->root->mutex. If some other vma in this mm shares
+* anon_vma->root->rwsem. If some other vma in this mm shares
* the same anon_vma we won't take it again.
*
* No need of atomic instructions here, head.next
* can't change from under us thanks to the
-* anon_vma->root->mutex.
+* anon_vma->root->rwsem.
*/
if (__test_and_set_bit(0, (unsigned long *)
_vma->root->rb_root.rb_node))
@@ -2671,7 +2671,7 @@ static void vm_unlock_anon_vma(struct an
*
* No need of atomic instructions here, head.next
Re: flush_to_ldisc accesses tty after free (was: [PATCH 21/21] TTY: move tty buffers to tty_port)
On Sat, 2012-12-01 at 09:59 -0500, Peter Hurley wrote:
> From instrumenting the tty_release() path, it's clear that tty_buffer
> work is still scheduled even after tty_release_ldisc() has run. For
> example, with this patch I get the warning below it.
>
> [Further analysis to follow in subsequent mail...]
[ Please note: this analysis only refers to the pty driver. The
situation with hardware drivers has further complications.]
Firstly, this problem predates Jiri's changes; only because he was
cautious by checking the lifetime of the itty in flush_to_ldisc(), did
he uncover this existing problem.
One example of how it is possible for buffer work to be scheduled even
after tty_release_ldisc() stems from how tty_ldisc_halt() works (or
rather doesn't). (I've snipped out the relevant code from tty_ldisc.c
for annotation below.)
tty_ldisc_halt() has only 2 callers; tty_release_ldisc() and
tty_set_ldisc(). A 3rd code site -- tty_ldisc_hangup() -- has similar
logic.
The idea behind tty_ldisc_halt() is to prevent __future__ use of this
ldisc (since users are required to acquire an ldisc reference via
tty_ldisc_try() -- also below). Annotations are mine.
--
static struct tty_ldisc *tty_ldisc_try(struct tty_struct *tty)
{
unsigned long flags;
struct tty_ldisc *ld;
/* this spin_lock is irrelevant to this discussion */
spin_lock_irqsave(_ldisc_lock, flags);
ld = NULL;
/*
* Atomically test if __new__ ldisc references are
* allowed. Please note, there can be any number of
* existing users (ie., outstanding references).
*/
if (test_bit(TTY_LDISC, >flags))
ld = get_ldisc(tty->ldisc);
spin_unlock_irqrestore(_ldisc_lock, flags);
return ld;
}
static int tty_ldisc_halt(struct tty_struct *tty)
{
/* Prevent any __new__ ldisc references from being acquired. */
clear_bit(TTY_LDISC, >flags);
/* Since __existing__ ldisc references can still schedule new
* buffer work (via tty_flip_buffer_push()), the cancellation
* below is pointless. The instant that cancellation completes
* an existing ldisc user can schedule new work.
*
* At a minimum, we must wait for all ldisc references **here**
* rather than **after** cancelling the work.
*/
return cancel_work_sync(>buf.work);
}
A special note about locking *
Locking around tty_ldisc_halt() ...
- does not prevent existing ldisc users from continuing to use the ldisc
- is unnecessary for the 3 'callers' because all 3 are trying to
accomplish the same goal by the same means
- can deadlock. Reference: https://lkml.org/lkml/2012/11/21/267
Regards,
Peter Hurley
--
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] gpio: stmpe: Add DT support for stmpe gpio
On Sat, Dec 1, 2012 at 8:34 PM, Linus Walleij wrote: > The crucial question is: can the STMPE controllers be > used for GPIO, PWM, keypad and touchscreen at the > *same time* or are they nailed to *one* usecase during > electronics design? Looking closer at the datasheet it seems to mux pins on individual per-pin basis, so it is indeed pin-controller-like. Was this driver submitted today, I would probably request that the pinctrl + GPIO properties be properly exposed in the pinctrl subsystem instead. Yours, Linus Walleij -- 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] gpio: stmpe: Add DT support for stmpe gpio
On Mon, Nov 26, 2012 at 12:28 PM, Lee Jones wrote: > On Fri, 23 Nov 2012, Shiraz Hashim wrote: [About st-norequest-mask] >> This is a board dependent parameter which just informs gpio driver >> about pins, which must not be requested. It may happen for a stmpe >> variant where such gpio pins are multiplexed with some other >> function. >> >> Hence it must be part of DT itself. > > Doesn't pinctrl normally handle this kind of stuff? So this is a signal that something might be strange about the driver architecture at large. The datasheet for STMPE1601 says: "The STMPE1601 offers great flexibility, as each I/O can be configured as input, output or specific functions." Hm hm. Well this driver existed before the pin control system so we have to live with this. We *could* assume that the above DT property could be set beacause someone connected a GPIO to ground and trying to use it would burn the system or something. But if it's actually dealing with the sideeffects of pinmuxing it's done in the wrong place. Apart from the pinctrl API another way to handle these beasts is what I do in the drivers/mfd/tps6105x.c, where the hardware is such that you basically always nail down the hardware for one specific use case of 3 possible. Then it's done by configuring the root MFD device. The crucial question is: can the STMPE controllers be used for GPIO, PWM, keypad and touchscreen at the *same time* or are they nailed to *one* usecase during electronics design? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] New driver: Xillybus generic interface for FPGA (programmable logic)
On 12/01/2012 08:56 AM, Greg KH wrote: On Fri, Nov 30, 2012 at 07:19:16PM -0800, Philip Balister wrote: On 11/30/2012 09:36 AM, Greg KH wrote: On Fri, Nov 30, 2012 at 05:28:47PM +, Arnd Bergmann wrote: On Wednesday 28 November 2012, Eli Billauer wrote: Xillybus is a general-purpose framework for communication between programmable logic (FPGA) and a host. It provides a simple connection between hardware FIFOs in the FPGA and their respective device files on the host. The user space programming model is like piping data from or to the FPGA. The underlying transport between the host and FPGA is either PCIe or AXI (AMBA bus by ARM). The Xillybus logic (IP core) is configurable in the number of pipes it presents and their nature. The driver autodetects these pipes, making it essentially forward-compatible to future configurations. The benefit of having this driver enabled in the kernel is that hardware vendors may release a new card, knowing that it will work out of the box on any future Linux machine, with the specific configuration defined for the FPGA part. This driver has been available for download for over a year, and has been actively used on a wide variety of kernels versions and configurations. I have a much higher-level comment on this driver: There seem to be a number of parties that are interested in having reprogrammable logic available in Linux and that will want to merge their drivers. I'm aware of these other people that must have some interest (and one person I can't mention here because of NDA): Philip Balister (OpenSDR) Dinh Nguyen (ARM SOCFPGA maintainer) Pavel Machek (SOCFPGA contributor) John Linn (Zynq maintainer) Michal Simek (Zynq maintainer) Ira W. Snyder (Carma driver author) Yes, I know of at least one more device other than the ones listed above that wants this type of functionality as well, so defining it in a standard user/kernel api manner would be very good to do. I'm concerned that a standard driver for FPGA's will be a very difficult problem. The Xillybus driver looks interesting on several levels, however my first concern is depends on a FPGA IP block that is not open source. This is not a bad thing, just a potential obstacle for some people. As long as that doesn't affect the kernel code, I don't see the obstacle here. What am I missing? Nothing. The Xillybus approach is valid. It just depends on their piece of fpga code. If you are not willing to license that, you will need to reverse engineer their fpga code, or sues a different (equally valid) method to communicate with the fpga. Think of their fpga blob as a specific implementation of a network card. Not all network cards expose the same hardware interface. The important thing to realize is that the fpga is user configurable. It is possible to create an infinite number of possible "devices" in it that can use any number of device drivers in Linux. Think of it a a soc, with a large part that the end user can customize with his own IP. In the Xilly case, they have created a custom piece of hardware in the fpga that needs a driver with a specific interface to users space. I've been engaged in design discussions today with my customer. Our target is the Xilinx Zynq hardware. The first pass at a driver focuses on creating the minimal amount of code in the kernel doing most of the logic in user space. So the driver code allocates a large chunk of RAM for the FPGA to read/write to, provides a mmap function so user space can see this RAM, also mmaps in the address space of an AXI slave so the user space can control the logic. This approach has no dependencies on what is loaded into the fpga. Would a simple UIO driver work best for this type of arrangement? Then those types of hardware wouldn't even need to mess with a fpga-type interface. It is very close to a UIO approach. My key problem I am trying to solve is getting a "large" buffer space for the driver and a way to communicate the physical address and size of the buffer to the fpga. The fpga has several ports that allow it to directly read/write RAM, but it needs to know physical addresses. This is a very different approach then the Xillybus driver, but should also be useful to a large class of people. Hopefully, we can converge on a set of useful drivers, and not end up with a million drivers all based on custom fpga configuration :) Odds are, this should look something like the firmware interface in the end, right? Userspace dumps a bunch of data to the device, and then needs the driver to toggle some bits somewhere to enable the device. Also, a few control calls like clearing the device, and other minor things should be all that is needed, right? For zynq, there is an out of tree ( :) ) driver that handles the firmware loading. This is an independent problem. So, in the grand tradition of, "The first one there wins", why not base it all off of your driver, and how that works, and we can go from
Re: [RFC v2 1/8] video: tegra: Add nvhost driver
On 01.12.2012 19:34, Lucas Stach wrote: > This would certainly make life easier, but personally I don't think it's > the right thing to do. The separation of the Linux kernel into different > subsystems was done for a reason and just because the specific hardware > at hands happens to work a bit different is no valid reason to break > with the standard rules of the kernel. > > So I think there is no way around handling the different drivers that > use host1x in different trees. For the time being there is _only_ > tegra-drm using host1x in the upstream kernel. We have to make sure to > come up with some API which is reasonably stable, so we don't run into > big problems later. That's why I'm really in favour to keep host1x and > tegra-drm side by side in the current upstream, to make sure we can > change the API without jumping through too much hoops. > > Your downstream V4L would have to use host1x from the DRM directory, but > really: is your downstream such a nice, clean codebase that you are not > able to cope with the slight ugliness of this solution? Ok, can do. I'll move the code base to drivers/gpu/drm/tegra/host1x. For downstream, the host1x driver implements all user space APIs (no drm, no v4l, etc) so the directory is of no consequence. If we immersed host1x driver totally with tegra-drm, that'd be a problem, but if I can keep a separation, that's fine. > Please make sure to remove any unnecessary cruft from host1x in the > process and don't try to make too big of a step at once. We only need > one type of memory within host1x: native host1x objects, no need to plan > for support of anything else. Also taking over ownership of the IOMMU > address space might take some more work in the IOMMU API. We can leave > this out completely for a start. Both Tegra 2 and 3 should be able to > work with CMA backed objects just fine. Ok, that simplifies the process. I'll just implement firewall and copy the strema over to kernel space unconditionally. Terje -- 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 v2 0/8] Support for Tegra 2D hardware
On Sat, Dec 01, 2012 at 07:08:12PM +0200, Terje Bergström wrote: > On 01.12.2012 16:45, Thierry Reding wrote: > > I did some prototyping on how a libdrm API could look like a few weeks > > back. I should clean the patches up some and push them to a public > > repository or to the mailing lists for review. > > Ok. Sorry about the delay - I recently learned I need separate > permission for user space contribution, so I'm pushing to get that > permission. Oh dear. Doesn't sound like fun. =) > > There isn't actually much more than a bit of framework along with two > > IOCTLs that allow creating and looking up a Tegra-specific GEM. The > > related kernel patches aren't available anywhere since I didn't deem > > them ready yet. At that time I wasn't even sure if we'd need special > > allocations other than what the dumb BO infrastructure provides. They > > implement some parts of what you've implemented in this series as well, > > with some slight differences. > > Ok, the BO infra is still under flux as we're designing the best place > and work split. Yes, I've put the prototype under a --enable-tegra-experimental-api switch, which has been used in the past for helpers that weren't finalized yet. > > While I can't find the quote right now, I seem to remember that you said > > at some point that you were planning on adding some 2D acceleration bits > > to libdrm. I don't think that's the right place. That code should rather > > go into the DDX. libdrm should instead provide a thin layer on top of > > the DRM IOCTLs to manage buffers and submit command streams. I hope I > > can finish the cleanup of my libdrm patches over the weekend and push > > them out so this may become clearer. Maybe I can even get the > > corresponding kernel patches pushed out. > > Yep, that's exactly what I actually posed as a question in one of the > earlier mails. We also agree that 2D bits should not stay in libdrm. > That's why we've kept the 2D bits design-wise separate from the host1x > stream generation. > > We don't yet have any other place to put 2D functions in, so we'll > probably post them as part of patch series to libdrm. We'll just add a > disclaimer that the 2D code won't remain in libdrm, and wanted to get > the code out to review as a code example. We can put the 2D code either > to a separate library or to DDX, whichever is preferred. FWIW, I've done some work on an initial DDX, which is basically a fork of xf86-video-modesetting rebranded and with some cleanup like ripping out the PCI support. I wanted to do some testing before pushing it out and I think I can get that done on Monday. Posting the code early is exactly the right thing to do. We still have to figure out quite a number of things and we can always move code between the various components of the whole stack. > The host1x command stream generation would still remain in libdrm. That > seems to be the pattern with other hardware. Yes, I fully agree. Thierry pgpntBsSuGBOD.pgp Description: PGP signature
Re: High context switch rate, ksoftirqd's chewing cpu
Hello, On Sat, Dec 01, 2012 at 06:11:10PM +0100, Zlatko Calusic wrote: > Sure. Please clarify, should I apply it on top of the previous one > or standalone? It's a replacement, so by itself. Thanks! -- tejun -- 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] mm/migration: Remove anon vma locking from try_to_unmap() use
On 12/01/2012 01:38 PM, Linus Torvalds wrote: On Sat, Dec 1, 2012 at 4:26 AM, Ingo Molnar wrote: So as a quick concept hack I wrote the patch attached below. (It's not signed off, see the patch description text for the reason.) Well, it confirms that anon_vma locking is a big problem, but as outlined in my other email it's completely incorrect from an actual behavior standpoint. Btw, I think the anon_vma lock could be made a spinlock The anon_vma lock used to be a spinlock, and was turned into a mutex by Peter, as part of an effort to make more of the VM preemptible. -- All rights reversed -- 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] mm/migration: Remove anon vma locking from try_to_unmap() use
On Sat, Dec 1, 2012 at 10:41 AM, Ingo Molnar wrote: > > I'll try the rwsem and see how it goes? Yeah. That should be an easy conversion (just convert everything to use the write-lock first, and then you can make one or two migration places use the read version). Side note: The mutex code tends to potentially generate slightly faster noncontended locks than rwsems, and it does have the MUTEX_SPIN_ON_OWNER feature that makes the contention case often *much* better, so there are real downsides to rw-semaphores. But for this load, it does seem like the scalability advantages of an rwsem *might* be worth it. Side note: in contrast, the rwlock spinning reader-writer locks are basically never a win - the downsides just about always negate any theoretical scalability advantage. rwsem's can work well, we already use it for mmap_sem, for example, to allow concurrent page faults, and it was a *big* scalabiloity win there. Although then we did the "drop mmap_sem over IO and retry", and that might have negated many of the advantages of the mmap_sem. > Hm, indeed. For performance runs I typically disable lock > debugging - which might have made me not directly notice some of > the performance problems. Yeah, lock debugging really tends to make anything that is close to contended be absolutely *horribly* contended. Doubly so for the mutexes because it disables the spinning code, but it's true in general too. Linus -- 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/
Updating the .mailmap file
Hello,
I was just browsing the shortlog and it looked to
me as if there are many double entries, i.e. the same person
being there with multiple email addresses.
So I wrote a script, which finds double names and adds them
to the .mailmap file. However manual checking, whether these
are really the same person is required.
---
#!/bin/bash
git shortlog -sne > shortlog.txt
# find double names in the shortlog
cat shortlog.txt |awk '{ NF--; $1=""; print }' |sort |uniq -d | sed 's/^ *//g'
> names.txt
while read line
do
echo "process name $line"
# get the current mailmap file in a state where each person is listed
# with their first line:
rm mailmap_tmp*
cat .mailmap |grep -v "^[# ]"|grep -v "^$" | sort > mailmap_tmp1
while read <&9 line2
do
nameonly="$(echo "$line2" |awk '{NF--; print}')"
grep -m1 "$nameonly" mailmap_tmp1 >> mailmap_tmp2
done 9< "mailmap_tmp1"
cat mailmap_tmp2 |uniq > mailmap_tmp3
# find all occurences of one name
cat shortlog.txt |grep "$line" | awk '{ $1=""; print }' | sed 's/^ *//g' >
currentname.txt
# get that guy alphabetically sorted into the mailmap file:
echo $line > name
cat mailmap_tmp3 name |sort > mailmap_tmp4
# find the place where we need to insert this
insertbeforeline=$(cat mailmap_tmp4 |grep -A1 "$line" |tail -n1)
if [ "$insertbeforeline" != "" ] ; then
# insert all in the middle of .mailmap:
while read <&9 line2; do
echo "adding line $line2 to mailmap before $insertbeforeline"
sed "/$insertbeforeline/i $line2" .mailmap > mailmap_tmp5
mv mailmap_tmp5 .mailmap
done 9< "currentname.txt"
else
# must appended to end
cat currentname.txt >> .mailmap
fi
git commit -a -m "Updating .mailmap file: Adding ${line}" > /dev/null
echo "---"
done < "names.txt"
rm mailmap_tmp*
rm shortlog.txt
rm names.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/12] Refactoring the ab8500 battery management drivers
On Fri, Nov 30, 2012 at 12:57 PM, Lee Jones wrote: > The aim of this and subsequent patch-sets is to refactor battery > management services provided by the ab8500 MFD. This first patch-set > brings a few modifications to the collection which happened on the > internal kernel, but were never Mainlined. There are lots more of > these to come. We also tidy-up some of the Device Tree related patches > which are currently pending in -next. > > drivers/mfd/ab8500-core.c |8 - > drivers/power/ab8500_bmdata.c | 517 > +++ > drivers/power/ab8500_btemp.c| 96 > drivers/power/ab8500_charger.c | 222 - > drivers/power/ab8500_fg.c | 123 +- > drivers/power/abx500_chargalg.c | 133 +- > include/linux/mfd/abx500.h |6 +- > 7 files changed, 592 insertions(+), 513 deletions(-) All of this looks good to me. Acked-by: Linus Walleij for all. Arun submitted the original driver, maybe he can throw in an ACK as well... Yours, Linus Walleij -- 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: How about a gpio_get(device *, char *) function?
On Thu, Nov 29, 2012 at 6:34 PM, Grant Likely wrote: > On Wed, 28 Nov 2012 12:38:38 +0900, Alex Courbot wrote: >> On Monday 26 November 2012 19:14:31 Grant Likely wrote: >> > I don't have any problem with a gpio_get function, but I do agree that >> > making it return an opaque handle is how it should be written with a new >> > set of accessors. The handle should probably be simply the pointer to >> > the _desc[number] which is a private table in gpiolib.c. The >> > definition of it isn't available outside of gpiolib.c >> >> That looks like a reasonable approach, but this would make the new API >> available only to systems that use GPIOlib. Shouldn't we be concerned about >> making this available to all GPIO implementations? Or is GPIOlib so widely >> used that we don't care? > > I'm tempted to say non-gpiolib is not supported. However, there isn't > anything that would prevent non-gpiolib users from implementing the api > themselves, but they'd need to provide their own handle.. I get the creeps when you say that ... Now I think I have to put on my TODO to remove a few custom GPIO implementations so it feels better. ;-) Yours, Linus Walleij -- 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] mm/migration: Remove anon vma locking from try_to_unmap() use
* Linus Torvalds wrote: > On Sat, Dec 1, 2012 at 4:26 AM, Ingo Molnar wrote: > > > > > > So as a quick concept hack I wrote the patch attached below. > > (It's not signed off, see the patch description text for the > > reason.) > > Well, it confirms that anon_vma locking is a big problem, but > as outlined in my other email it's completely incorrect from > an actual behavior standpoint. Yeah. > Btw, I think the anon_vma lock could be made a spinlock > instead of a mutex or rwsem, but that would probably take more > work. We *shouldn't* be doing anything that needs IO inside > the anon_vma lock, though, so it *should* be doable. But there > are probably quite a bit of allocations inside the lock, and I > know it covers huge areas, so a spinlock might not only be > hard to convert to, it quite likely has latency issues too. I'll try the rwsem and see how it goes? > Oh, btw, MUTEX_SPIN_ON_OWNER may well improve performance too, > but it gets disabled by DEBUG_MUTEXES. So some of the > performance impact of the vma locking may be *very* > kernel-config dependent. Hm, indeed. For performance runs I typically disable lock debugging - which might have made me not directly notice some of the performance problems. Thanks, Ingo -- 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] staging, android, ashmem: invalidate pin/unpin ioctl for private map
On Sat, Dec 01, 2012 at 02:45:57AM +0900, Joonsoo Kim wrote:
> @@ -614,21 +616,35 @@ static int ashmem_pin_unpin(struct ashmem_area *asma,
> unsigned long cmd,
> pgstart = pin.offset / PAGE_SIZE;
> pgend = pgstart + (pin.len / PAGE_SIZE) - 1;
>
> - mutex_lock(_mutex);
> + if (asma->shared_mapping) {
> + mutex_lock(_mutex);
Wouldn't we need to hold the mutex while we check the
->shared_mapping?
regards,
dan carpenter
--
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] mm/migration: Remove anon vma locking from try_to_unmap() use
On Sat, Dec 1, 2012 at 4:26 AM, Ingo Molnar wrote: > > > So as a quick concept hack I wrote the patch attached below. > (It's not signed off, see the patch description text for the > reason.) Well, it confirms that anon_vma locking is a big problem, but as outlined in my other email it's completely incorrect from an actual behavior standpoint. Btw, I think the anon_vma lock could be made a spinlock instead of a mutex or rwsem, but that would probably take more work. We *shouldn't* be doing anything that needs IO inside the anon_vma lock, though, so it *should* be doable. But there are probably quite a bit of allocations inside the lock, and I know it covers huge areas, so a spinlock might not only be hard to convert to, it quite likely has latency issues too. Oh, btw, MUTEX_SPIN_ON_OWNER may well improve performance too, but it gets disabled by DEBUG_MUTEXES. So some of the performance impact of the vma locking may be *very* kernel-config dependent. Linus -- 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] gpio: stmpe: Add DT support for stmpe gpio
On Sat, Dec 1, 2012 at 10:05 PM, Linus Walleij wrote: > On Mon, Nov 26, 2012 at 12:32 PM, Shiraz Hashim wrote: >> On Mon, Nov 26, 2012 at 11:28:23AM +, Lee Jones wrote: >>> >>> Doesn't pinctrl normally handle this kind of stuff? >> >> Yes, but I think it is only for managing the SoC and its pads. > > No pinctrl is also for off-SoC pin controllers, you can have > pinctrl0, pinctrl1 ... pinctrlN on a system. The number space is > local per-pincontroller too. OK. Thanks for correcting. -- regards Shiraz Hashim -- 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] mm/migration: Don't lock anon vmas in rmap_walk_anon()
* Linus Torvalds wrote: > On Sat, Dec 1, 2012 at 1:49 AM, Ingo Molnar wrote: > > > > I *think* you are right that for this type of migration that > > we are using here we indeed don't need to take an exclusive > > vma lock - in fact I think we don't need to take it at all: > > I'm pretty sure we do need at least a read-side reference. Ok. > Even if no other MM can contain that particular pte, the vma > lock protects the chain that is created by fork and exit and > vma splitting etc. > > So it's enough that another thread does a fork() at the same > time. Or a partial unmap of the vma (that splits it in two), > for the rmap chain to be modified. > > Besides, there's absolutely nothing that protects that vma to > be part of the same vma chain in entirely unrelated processes. > The vma chain can get quite long over multiple forks (it's > even a performance problem under some extreme loads). > > And we do walk the rmap chain - so we need the lock. > > But we walk it read-only afaik, which is why I think the > semaphore could be an rwsem. > > Now, there *are* likely cases where we could avoid anon_vma > locking entirely, but they are very specialized. They'd be > along the lines of > > - we hold the page table lock > - we see that vma->anon_vma == vma->anon_vma->root > - we see that vma->anon_vma->refcount == 1 > > or similar, because then we can guarantee that the anon-vma > chain has a length of one without even locking, and holding > the page table lock means that any concurrent fork or > mmap/munmap from another thread will block on this particular > pte. Hm. These conditions may be true for some pretty common cases, but it's difficult to discover that information from the migration code due to the way we discover all anon vmas and walk the anon vma list: we first lock the anon vma then do we get to iterate over the individual vmas and do the pte changes. So it's the wrong way around. I think your rwsem suggestion is a lot more generic and more robust as well. > So I suspect that in the above kind of special case (which > might be a somewhat common case for normal page faults, for > example) we could make a "we have exclusive pte access to this > page" argument. But quite frankly, I completely made the above > rules up in my head, they may be bogus too. > > For the general migration case, it's definitely not possible > to just drop the anon_vma lock. Ok, I see - I'll redo this part then and try out how an rwsem fares. I suspect it would give a small speedup to a fair number of workloads, so it's worthwile to spend some time on it. Thanks for the suggestions! Ingo -- 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] ARM: Dove: Add pinctrl clock to DT
On Sat, Dec 01, 2012 at 07:15:55PM +0100, Sebastian Hesselbarth wrote: > On 12/01/2012 07:13 PM, Jason Cooper wrote: > >On Sat, Dec 01, 2012 at 06:07:06PM +0100, Linus Walleij wrote: > >>On Mon, Nov 26, 2012 at 10:18 AM, Sebastian Hesselbarth > >> wrote: > >> > >>>During merge of the mvebu patches a clock gate for pinctrl was > >>>lost. This patch just readds the clock gate. > >>> > >>>Signed-off-by: Sebastian Hesselbarth > >> > >>Acked-by: Linus Walleij > >> > >>So who's supposed to merge this patch? Me? The MVEBU-maintainer? > > > >I'll take it and merge it in once v3.8-rc1 drops. > > Linus, Jason, > > I agree to take it through Jason's tree but please take v2 of > the patch as there has been a small change in one of the patches. Yes, I have it flagged. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: Dove: Add pinctrl clock to DT
On 12/01/2012 07:13 PM, Jason Cooper wrote: On Sat, Dec 01, 2012 at 06:07:06PM +0100, Linus Walleij wrote: On Mon, Nov 26, 2012 at 10:18 AM, Sebastian Hesselbarth wrote: During merge of the mvebu patches a clock gate for pinctrl was lost. This patch just readds the clock gate. Signed-off-by: Sebastian Hesselbarth Acked-by: Linus Walleij So who's supposed to merge this patch? Me? The MVEBU-maintainer? I'll take it and merge it in once v3.8-rc1 drops. Linus, Jason, I agree to take it through Jason's tree but please take v2 of the patch as there has been a small change in one of the patches. Sebastian -- 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] ARM: Dove: Add pinctrl clock to DT
On Sat, Dec 01, 2012 at 06:07:06PM +0100, Linus Walleij wrote: > On Mon, Nov 26, 2012 at 10:18 AM, Sebastian Hesselbarth > wrote: > > > During merge of the mvebu patches a clock gate for pinctrl was > > lost. This patch just readds the clock gate. > > > > Signed-off-by: Sebastian Hesselbarth > > Acked-by: Linus Walleij > > So who's supposed to merge this patch? Me? The MVEBU-maintainer? I'll take it and merge it in once v3.8-rc1 drops. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] ux500: convert struct spinlock to spinlock_t
On Thu, Nov 29, 2012 at 9:45 PM, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > spinlock_t should always be used. > > I was unable to build test with allmodconfig: > > mcgrof@frijol ~/linux-next (git::(no branch))$ make C=1 > M=drivers/crypto/ux500/ > > WARNING: Symbol version dump /home/mcgrof/linux-next/Module.symvers >is missing; modules will have no dependencies and modversions. > > LD drivers/crypto/ux500/built-in.o > Building modules, stage 2. > MODPOST 0 modules > > Cc: Srinidhi Kasagar > Cc: Linus Walleij > Cc: linux-arm-ker...@lists.infradead.org > Reported-by: Hauke Mehrtens > Signed-off-by: Luis R. Rodriguez Looks correct to me. Acked-by: Linus Walleij Yours, Linus Walleij -- 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] ab8500: remove explicit handling of battery type
Hi,
On 11/28/2012 08:27 PM, Rajanikanth H.V wrote:
> From: "Rajanikanth H.V"
>
> property, battery-type shall be one of supported technology type
> instead blank
> - refer: Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
> for the list supported types
> - this patch appends to ab8500 bm devs DT binding patch set
> ref: commit-id e0f1abeba5c2d8a2183566717d99294fd1a29c2e
> git://git.infradead.org/battery-2.6.git
> - promote ab8500_fg probe to happen before ab8500_btemp probe as
> btemp driver depends on fuelgauge list,
> ref: ab8500_fg_get(...)
>
> Signed-off-by: Rajanikanth H.V
> ---
> drivers/power/Makefile|2 +-
> drivers/power/ab8500_bmdata.c | 10 +++---
> 2 files changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index 696e3a9..070c73d 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -38,7 +38,7 @@ obj-$(CONFIG_CHARGER_PCF50633) += pcf50633-charger.o
> obj-$(CONFIG_BATTERY_JZ4740) += jz4740-battery.o
> obj-$(CONFIG_BATTERY_INTEL_MID) += intel_mid_battery.o
> obj-$(CONFIG_BATTERY_RX51) += rx51_battery.o
> -obj-$(CONFIG_AB8500_BM) += ab8500_bmdata.o ab8500_charger.o
> ab8500_btemp.o ab8500_fg.o abx500_chargalg.o
> +obj-$(CONFIG_AB8500_BM) += ab8500_bmdata.o ab8500_charger.o
> ab8500_fg.o ab8500_btemp.o abx500_chargalg.o
> obj-$(CONFIG_CHARGER_ISP1704)+= isp1704_charger.o
> obj-$(CONFIG_CHARGER_MAX8903)+= max8903_charger.o
> obj-$(CONFIG_CHARGER_TWL4030)+= twl4030_charger.o
> diff --git a/drivers/power/ab8500_bmdata.c b/drivers/power/ab8500_bmdata.c
> index 03cc528..f16b60c 100644
> --- a/drivers/power/ab8500_bmdata.c
> +++ b/drivers/power/ab8500_bmdata.c
> @@ -461,7 +461,6 @@ bmdevs_of_probe(struct device *dev,
> struct device_node *np_bat_supply;
> struct abx500_bm_data *bat;
> const char *btech;
> - char bat_tech[8];
> int i, thermistor;
>
> *battery = _bm_data;
> @@ -488,12 +487,9 @@ bmdevs_of_probe(struct device *dev,
> "stericsson,battery-type", NULL);
> if (!btech) {
> dev_warn(dev, "missing property battery-name/type\n");
> - strcpy(bat_tech, "UNKNOWN");
> - } else {
> - strcpy(bat_tech, btech);
> + return -EINVAL;
Before returning, of_node_put() should be called on the device node.
--
Francesco
--
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] irqdomain: update documentation
This updates the IRQdomain documentation a bit, by adding a more verbose explanation to why we need this, and by adding some extended documentation of the irq_domain_simple() usecase. Signed-off-by: Linus Walleij --- Documentation/IRQ-domain.txt | 34 +- 1 file changed, 33 insertions(+), 1 deletion(-) diff --git a/Documentation/IRQ-domain.txt b/Documentation/IRQ-domain.txt index 1401cec..9bc9594 100644 --- a/Documentation/IRQ-domain.txt +++ b/Documentation/IRQ-domain.txt @@ -7,6 +7,21 @@ systems with multiple interrupt controllers the kernel must ensure that each one gets assigned non-overlapping allocations of Linux IRQ numbers. +The number of interrupt controllers registered as unique irqchips +show a rising tendency: for example subdrivers of different kinds +such as GPIO controllers avoid reimplementing identical callback +mechanisms as the IRQ core system by modelling their interrupt +handlers as irqchips, i.e. in effect cascading interrupt controllers. + +Here the interrupt number loose all kind of correspondence to +hardware interrupt numbers: whereas in the past, IRQ numbers could +be chosen so they matched the hardware IRQ line into the root +interrupt controller (i.e. the component actually fireing the +interrupt line to the CPU) nowadays this number is just a number. + +For this reason we need a mechanism to separate controller-local +interrupt numbers, called hardware irq's, from Linux IRQ numbers. + The irq_alloc_desc*() and irq_free_desc*() APIs provide allocation of irq numbers, but they don't provide any support for reverse mapping of the controller-local IRQ (hwirq) number into the Linux IRQ number @@ -40,6 +55,10 @@ required hardware setup. When an interrupt is received, irq_find_mapping() function should be used to find the Linux IRQ number from the hwirq number. +The irq_create_mapping() function must be called *atleast once* +before any call to irq_find_mapping(), lest the descriptor will not +be allocated. + If the driver has the Linux IRQ number or the irq_data pointer, and needs to know the associated hwirq number (such as in the irq_chip callbacks) then it can be directly obtained from irq_data->hwirq. @@ -119,4 +138,17 @@ numbers. Most users of legacy mappings should use irq_domain_add_simple() which will use a legacy domain only if an IRQ range is supplied by the -system and will otherwise use a linear domain mapping. +system and will otherwise use a linear domain mapping. The semantics +of this call are such that if an IRQ range is specified then +descriptors will be allocated on-the-fly for it, and if no range is +specified it will fall through to irq_domain_add_linear() which meand +*no* irq descriptors will be allocated. + +A typical use case for simple domains is where an irqchip provider +is supporting both dynamic and static IRQ assignments. + +In order to avoid ending up in a situation where a linear domain is +used and no descriptor gets allocated it is very important to make sure +that the driver using the simple domain call irq_create_mapping() +before any irq_find_mapping() since the latter will actually work +for the static IRQ assignment case. -- 1.7.11.7 -- 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] mm/migration: Don't lock anon vmas in rmap_walk_anon()
On Sat, Dec 1, 2012 at 1:49 AM, Ingo Molnar wrote: > > I *think* you are right that for this type of migration that we > are using here we indeed don't need to take an exclusive vma > lock - in fact I think we don't need to take it at all: I'm pretty sure we do need at least a read-side reference. Even if no other MM can contain that particular pte, the vma lock protects the chain that is created by fork and exit and vma splitting etc. So it's enough that another thread does a fork() at the same time. Or a partial unmap of the vma (that splits it in two), for the rmap chain to be modified. Besides, there's absolutely nothing that protects that vma to be part of the same vma chain in entirely unrelated processes. The vma chain can get quite long over multiple forks (it's even a performance problem under some extreme loads). And we do walk the rmap chain - so we need the lock. But we walk it read-only afaik, which is why I think the semaphore could be an rwsem. Now, there *are* likely cases where we could avoid anon_vma locking entirely, but they are very specialized. They'd be along the lines of - we hold the page table lock - we see that vma->anon_vma == vma->anon_vma->root - we see that vma->anon_vma->refcount == 1 or similar, because then we can guarantee that the anon-vma chain has a length of one without even locking, and holding the page table lock means that any concurrent fork or mmap/munmap from another thread will block on this particular pte. So I suspect that in the above kind of special case (which might be a somewhat common case for normal page faults, for example) we could make a "we have exclusive pte access to this page" argument. But quite frankly, I completely made the above rules up in my head, they may be bogus too. For the general migration case, it's definitely not possible to just drop the anon_vma lock. Linus -- 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] gpio: stmpe: Add DT support for stmpe gpio
On 1 December 2012 22:17, Linus Walleij wrote: > If you can, try to avoid this: > Content-Type: text/plain; charset=WINDOWS-1252 > Content-Transfer-Encoding: quoted-printable > > That kind om message encoding makes my life a living hell > (but I fixed it, manually editing the whole patch) how did you > end up with this? Did you for example issue the command > git send-email from a Windows machine using some Windows > version of git? I don't use windows for any linux work. I went through the header to see what went wrong and realized, i sent this mail when i was in ARM's office and via arm id only. i.e. using arm id's msmtprc settings. I don't know why my linaro settings don't work from office, they work from outside with no changes. companies use microsoft exchange server and that played with this patch. Sorry for making your life miserable :( -- viresh -- 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 v2 1/8] video: tegra: Add nvhost driver
Am Samstag, den 01.12.2012, 18:55 +0200 schrieb Terje Bergström: > On 01.12.2012 17:10, Thierry Reding wrote: > > On Sat, Dec 01, 2012 at 01:44:41PM +0200, Terje Bergström wrote: > >> host1x module being in DRM directory hinders using nvhost from anywhere > >> outside DRM in both upstream and downstream. > > > > That's not true. Nothing keeps the rest of the kernel from using an API > > exported by the tegra-drm driver. > > Right, it's just a directory. I was actually thinking that it'd be weird > if a V4L2 driver would use something from inside drivers/gpu/drm/tegra > (V4L use DRM? Oh no!). > Yes it _is_ weird to have V4L using something which resides inside DRM, but see below. > Shoot the idea down if it's crazy, but please think about it first. :-) > > I started thinking about this and we are constrained by the Linux kernel > subsystems that have a complete different architecture than hardware. > This leads to awkward design as DRM design as it conflicts with the way > hardware works. > > Placing host1x driver in one place, DRM driver in another and XYZ driver > in yet another is not ideal either. We're exposing a public API which > needs to be strictly maintained, because we maintain drivers in > different trees, but then again, the list of users is very static and > well-defined, so public API is an overshoot. > How about if we look at this from the hardware architecture point of > view? You mentioned that perhaps drivers/bus/host1x would be the best > place for host1x driver. > > What if we put also all host1x client modules under that same directory? > drivers/bus/host1x/drm would be for DRM interface, and all other host1x > client module drivers could be placed similarly. This way we could keep > the host1x API private to host1x and the client module drivers, and it's > easy to understand how host1x is used by just following the directory > structure. > This would certainly make life easier, but personally I don't think it's the right thing to do. The separation of the Linux kernel into different subsystems was done for a reason and just because the specific hardware at hands happens to work a bit different is no valid reason to break with the standard rules of the kernel. So I think there is no way around handling the different drivers that use host1x in different trees. For the time being there is _only_ tegra-drm using host1x in the upstream kernel. We have to make sure to come up with some API which is reasonably stable, so we don't run into big problems later. That's why I'm really in favour to keep host1x and tegra-drm side by side in the current upstream, to make sure we can change the API without jumping through too much hoops. Your downstream V4L would have to use host1x from the DRM directory, but really: is your downstream such a nice, clean codebase that you are not able to cope with the slight ugliness of this solution? > Naturally, we could also think if we want to have sub-components per > host1x client (dc, 2d, etc) and a drm sub-component that implements the > DRM interface, and a V4L2 sub-component that implements V4L2 interface > (when/if I can convince people that camera should go upstream). > To me this sound as if V4L upstream support is still a fair time away. IMHO the right time to move out host1x is exactly the point when a second user starts appearing upstream. This will give us some time to fiddle with the API until we have to commit to it as being stable. > >> I also don't like first putting the driver in one place, and then > >> moving it with a huge commit to another place. > > > > Hehe, you're doing exactly that in this patch series. =) > > True, I guess it's just a matter of determining what's the best time. > See above. [...] > I'm not in a hurry, so let's try to figure the best design first. > Biggest architectural unsolved problem is the memory management and > relationship between tegradrm and host1x driver. What Lucas proposed > about memory management makes sense, but it'll take a while to implement it. Please make sure to remove any unnecessary cruft from host1x in the process and don't try to make too big of a step at once. We only need one type of memory within host1x: native host1x objects, no need to plan for support of anything else. Also taking over ownership of the IOMMU address space might take some more work in the IOMMU API. We can leave this out completely for a start. Both Tegra 2 and 3 should be able to work with CMA backed objects just fine. Regards, Lucas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 2/2] clk: per-user clock accounting for debug
On Wed, Nov 28, 2012 at 12:52 PM, Rabin Vincent
wrote:
> When a clock has multiple users, the WARNING on imbalance of
> enable/disable may not show the guilty party since although they may
> have commited the error earlier, the warning is emitted later when some
> other user, presumably innocent, disables the clock.
>
> Provide per-user clock enable/disable accounting and disabler tracking
> in order to help debug these problems.
>
> NOTE: with this patch, clk_get_parent() behaves like clk_get(), i.e. it
> needs to be matched with a clk_put(). Otherwise, memory will leak.
>
> Signed-off-by: Rabin Vincent
Overall this looks very helpful.
> @@ -504,7 +525,15 @@ void clk_disable(struct clk *clk_user)
> unsigned long flags;
>
> spin_lock_irqsave(_lock, flags);
> - __clk_disable(clk);
> + if (!WARN(clk_user->enable_count == 0,
> + "incorrect disable clk dev %s con %s last disabler %pF\n",
> + clk_user->dev_id, clk_user->con_id,
> clk_user->last_disable)) {
> +
> + clk_user->last_disable = __builtin_return_address(0);
> + clk_user->enable_count--;
> +
> + __clk_disable(clk);
> + }
It seems as if an unbalanced clk_disable() call is done before any
clk_enable() call something like:
"incorrect disable clk dev foo con bar last disabler (null)"
Then the second WARN() will be triggered in __clk_disable().
Have you tried this usecase?
Maybe we can avoid the confusing warning, I don't know.
No big deal maybe.
Apart from that:
Acked-by: Linus Walleij
Yours,
Linus Walleij
--
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 1/2] clk: use struct clk only for external API
On Wed, Nov 28, 2012 at 12:52 PM, Rabin Vincent wrote: > In order to provide per-user accounting, this separates the struct clk > used in the common clock framework into two structures 'struct clk_core' > and 'struct clk'. struct clk_core will be used for internal > manipulation and struct clk will be used in the clock API > implementation. > > In this patch, struct clk is simply renamed to struct clk_core and a new > struct clk is implemented which simply wraps it. In the next patch, the > new struct clk will be used to implement per-user clock enable > accounting. > > There is a rather hacky #define of clk_core to clk for the non-common > clk case in order to avoid a mass rename of all clk non-common clk > implementations. > > Signed-off-by: Rabin Vincent I like the spirit of this and I think it was Thomas Gleixner who early on strongly recommended that the struct be kept as private as possible. Acked-by: Linus Walleij Yours, Linus Walleij -- 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: [ 00/37] 3.0.54-stable review
On Sat, Dec 1, 2012 at 9:24 AM, David Miller wrote: > > Satoru, I just want to let you know that, because you encode your > emails using ISO-2022-JP-2, nearly half of the subscribers to > the vger.kernel.org mailing lists bounce your postings. > > I know it's stupid, and it's mostly a Microsoft Exchange issue, > but it does mean that people that you may wish to see your emails > are not. This includes developers at major sites such as cisco.com > and intel.com > > I even saw toshiba.co.jp bounce your postings because of this encoding > issue. > > Anyways, just FYI... Satoru, hp.com addresses have the same issue and I keep cc'ing all my emails from hp.com to my gmail address so I don't miss any responses. Again just FYI. -- Shuah -- 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] mfd: wm5102: Add readback of DSP status 3 register
Signed-off-by: Mark Brown --- drivers/mfd/wm5102-tables.c |2 ++ include/linux/mfd/arizona/registers.h |1 + 2 files changed, 3 insertions(+) diff --git a/drivers/mfd/wm5102-tables.c b/drivers/mfd/wm5102-tables.c index e9063ab..b82a003 100644 --- a/drivers/mfd/wm5102-tables.c +++ b/drivers/mfd/wm5102-tables.c @@ -1822,6 +1822,7 @@ static bool wm5102_readable_register(struct device *dev, unsigned int reg) case ARIZONA_DSP1_CLOCKING_1: case ARIZONA_DSP1_STATUS_1: case ARIZONA_DSP1_STATUS_2: + case ARIZONA_DSP1_STATUS_3: return true; default: if ((reg >= 0x10 && reg < 0x106000) || @@ -1878,6 +1879,7 @@ static bool wm5102_volatile_register(struct device *dev, unsigned int reg) case ARIZONA_AOD_IRQ_RAW_STATUS: case ARIZONA_DSP1_STATUS_1: case ARIZONA_DSP1_STATUS_2: + case ARIZONA_DSP1_STATUS_3: case ARIZONA_HEADPHONE_DETECT_2: case ARIZONA_MIC_DETECT_3: return true; diff --git a/include/linux/mfd/arizona/registers.h b/include/linux/mfd/arizona/registers.h index ba26e99..1f6fe31 100644 --- a/include/linux/mfd/arizona/registers.h +++ b/include/linux/mfd/arizona/registers.h @@ -981,6 +981,7 @@ #define ARIZONA_DSP1_CLOCKING_1 0x1101 #define ARIZONA_DSP1_STATUS_10x1104 #define ARIZONA_DSP1_STATUS_20x1105 +#define ARIZONA_DSP1_STATUS_30x1106 #define ARIZONA_DSP2_CONTROL_1 0x1200 #define ARIZONA_DSP2_CLOCKING_1 0x1201 #define ARIZONA_DSP2_STATUS_10x1204 -- 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: [RFC v2 1/8] video: tegra: Add nvhost driver
On 01.12.2012 16:58, Thierry Reding wrote: > I don't know where you see politics in what I said. All I'm saying is > that we shouldn't be making things needlessly complex. In my experience > the technically cleanest solution is usually the one with the least > complexity. Let me come up with a proposal and let's then see where to go next. > But you already have extra code in the kernel to patch out expired sync- > points. Is it really worth the added effort to burden userspace with > this? If so I still think some kind of generic IOCTL to retrieve > information about a syncpoint would be better than a sysfs interface. That's exactly why I mentioned that it's not useful to upstream. There are some cases where user space might want to check if a fence has passed without waiting for it, but that's marginal and could be handled even with waits with zero timeout. Terje -- 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] mfd: wm5102: Add tuning for revision B
Evaluation of revision B of WM5102 suggests updates to the register patch
for optimal performance, and make this the default behaviour for new
devices.
Signed-off-by: Mark Brown
---
drivers/mfd/wm5102-tables.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/wm5102-tables.c b/drivers/mfd/wm5102-tables.c
index 8bd0504..36708b0 100644
--- a/drivers/mfd/wm5102-tables.c
+++ b/drivers/mfd/wm5102-tables.c
@@ -56,6 +56,18 @@ static const struct reg_default wm5102_reva_patch[] = {
{ 0x80, 0x },
};
+static const struct reg_default wm5102_revb_patch[] = {
+ { 0x80, 0x0003 },
+ { 0x081, 0xE022 },
+ { 0x410, 0x6080 },
+ { 0x418, 0x6080 },
+ { 0x420, 0x6080 },
+ { 0x428, 0xC000 },
+ { 0x441, 0x8014 },
+ { 0x458, 0x000b },
+ { 0x80, 0x },
+};
+
/* We use a function so we can use ARRAY_SIZE() */
int wm5102_patch(struct arizona *arizona)
{
@@ -65,7 +77,9 @@ int wm5102_patch(struct arizona *arizona)
wm5102_reva_patch,
ARRAY_SIZE(wm5102_reva_patch));
default:
- return 0;
+ return regmap_register_patch(arizona->regmap,
+wm5102_revb_patch,
+ARRAY_SIZE(wm5102_revb_patch));
}
}
--
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] mfd: arizona: Defer patch initialistation until after first device boot
Make sure that we don't race with the initial device boot by only doing
the initialisation after we've waited for the boot to complete.
The runtime PM code already waits for the boot to complete before it
syncs the register patches so in most systems if a race does occur we will
power down very soon afterwards and recover anyway.
Reported-by: Charles Keepax
Signed-off-by: Mark Brown
---
drivers/mfd/arizona-core.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index c784f46..f1ed9ae 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -292,6 +292,7 @@ int arizona_dev_init(struct arizona *arizona)
struct device *dev = arizona->dev;
const char *type_name;
unsigned int reg, val;
+ int (*apply_patch)(struct arizona *) = NULL;
int ret, i;
dev_set_drvdata(arizona->dev, arizona);
@@ -391,7 +392,7 @@ int arizona_dev_init(struct arizona *arizona)
arizona->type);
arizona->type = WM5102;
}
- ret = wm5102_patch(arizona);
+ apply_patch = wm5102_patch;
break;
#endif
#ifdef CONFIG_MFD_WM5110
@@ -402,7 +403,7 @@ int arizona_dev_init(struct arizona *arizona)
arizona->type);
arizona->type = WM5110;
}
- ret = wm5110_patch(arizona);
+ apply_patch = wm5110_patch;
break;
#endif
default:
@@ -412,9 +413,6 @@ int arizona_dev_init(struct arizona *arizona)
dev_info(dev, "%s revision %c\n", type_name, arizona->rev + 'A');
- if (ret != 0)
- dev_err(arizona->dev, "Failed to apply patch: %d\n", ret);
-
/* If we have a /RESET GPIO we'll already be reset */
if (!arizona->pdata.reset) {
regcache_mark_dirty(arizona->regmap);
@@ -438,6 +436,14 @@ int arizona_dev_init(struct arizona *arizona)
goto err_reset;
}
+ if (apply_patch) {
+ ret = apply_patch(arizona);
+ if (ret != 0)
+ dev_err(arizona->dev, "Failed to apply patch: %d\n",
+ ret);
+ goto err_reset;
+ }
+
for (i = 0; i < ARRAY_SIZE(arizona->pdata.gpio_defaults); i++) {
if (!arizona->pdata.gpio_defaults[i])
continue;
--
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: High context switch rate, ksoftirqd's chewing cpu
On 01.12.2012 15:38, Tejun Heo wrote: Hello, On Sat, Dec 01, 2012 at 12:06:41PM +0100, Zlatko Calusic wrote: I have good news. The patch fixes the regression! To doublecheck and provide you additional data, I updated to the latest Linus kernel (commit 7c17e48), recompiled (WITHOUT the patch), rebooted and this is what vmstat 1 looks like: Awesome, can you please test the following patch too? Thanks! Sure. Please clarify, should I apply it on top of the previous one or standalone? -- Zlatko -- 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 v2 0/8] Support for Tegra 2D hardware
On 01.12.2012 16:45, Thierry Reding wrote: > I did some prototyping on how a libdrm API could look like a few weeks > back. I should clean the patches up some and push them to a public > repository or to the mailing lists for review. Ok. Sorry about the delay - I recently learned I need separate permission for user space contribution, so I'm pushing to get that permission. > There isn't actually much more than a bit of framework along with two > IOCTLs that allow creating and looking up a Tegra-specific GEM. The > related kernel patches aren't available anywhere since I didn't deem > them ready yet. At that time I wasn't even sure if we'd need special > allocations other than what the dumb BO infrastructure provides. They > implement some parts of what you've implemented in this series as well, > with some slight differences. Ok, the BO infra is still under flux as we're designing the best place and work split. > Currently these still use the CMA-backed GEM objects but it should be > easy to switch to something backed by the host1x infrastructure once > that's in good shape. Sounds good. > While I can't find the quote right now, I seem to remember that you said > at some point that you were planning on adding some 2D acceleration bits > to libdrm. I don't think that's the right place. That code should rather > go into the DDX. libdrm should instead provide a thin layer on top of > the DRM IOCTLs to manage buffers and submit command streams. I hope I > can finish the cleanup of my libdrm patches over the weekend and push > them out so this may become clearer. Maybe I can even get the > corresponding kernel patches pushed out. Yep, that's exactly what I actually posed as a question in one of the earlier mails. We also agree that 2D bits should not stay in libdrm. That's why we've kept the 2D bits design-wise separate from the host1x stream generation. We don't yet have any other place to put 2D functions in, so we'll probably post them as part of patch series to libdrm. We'll just add a disclaimer that the 2D code won't remain in libdrm, and wanted to get the code out to review as a code example. We can put the 2D code either to a separate library or to DDX, whichever is preferred. The host1x command stream generation would still remain in libdrm. That seems to be the pattern with other hardware. Best regards, Terje -- 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] ARM: Dove: Add pinctrl clock to DT
On Mon, Nov 26, 2012 at 10:18 AM, Sebastian Hesselbarth wrote: > During merge of the mvebu patches a clock gate for pinctrl was > lost. This patch just readds the clock gate. > > Signed-off-by: Sebastian Hesselbarth Acked-by: Linus Walleij So who's supposed to merge this patch? Me? The MVEBU-maintainer? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/8] mmc: use the new
On Fri, Nov 23, 2012 at 4:08 PM, Davide Ciminaghi wrote: > From: Alessandro Rubini > > Signed-off-by: Alessandro Rubini > Acked-by: Giancarlo Asnaghi Acked-by: Linus Walleij Yours, Linus Walleij -- 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] input: gpio-keys: Disable hardware on suspend
On Sun, Nov 25, 2012 at 9:32 AM, Dmitry Torokhov wrote: > On Thu, Nov 22, 2012 at 01:23:36PM +, Lee Jones wrote: >> From: Jonas Aaberg >> >> Disable hardware if active when suspending if the hw can not >> wake the system from suspend. > > How about below instead (needs the other patch I have just sent out)? LooksGoodToMe(TM) Acked-by. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] New driver: Xillybus generic interface for FPGA (programmable logic)
On Sat, Dec 01, 2012 at 08:56:12AM -0800, Greg KH wrote: > So, in the grand tradition of, "The first one there wins", why not base > it all off of your driver, and how that works, and we can go from there :) Oops, sorry s/your/Eli's/, my confusion. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Input: gpio_keys - report initial state when opening the device
On Sun, Nov 25, 2012 at 9:31 AM, Dmitry Torokhov wrote: > Instead of reporting the initial stage when the device is registered we > should do it when the device is opened (so there are users). > > Signed-off-by: Dmitry Torokhov Makes perfect sense. Acked-by: Linus Walleij Yours, Linus Walleij -- 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/
