- 17 11月, 2012 2 次提交
-
-
由 Andreas Larsson 提交于
i2c: ocores: Add support for the GRLIB port of the controller and use function pointers for getreg and setreg functions The registers in the GRLIB port of the controller are 32-bit and in big endian byte order. The PRELOW and PREHIGH registers are merged into one register. The subsequent registers have their offset decreased accordingly. Hence the register access needs to be handled in a non-standard manner using custom getreg and setreg functions. Add setreg and getreg functions for different register widths and let oc_setreg and oc_getreg use function pointers to call the appropriate functions. A type is added as the data of the of match table entries. A new entry with a different compatible string is added to the table. The type of that entry triggers usage of the custom grlib functions by setting the setreg and getreg function pointers. Signed-off-by: NAndreas Larsson <andreas@gaisler.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Andreas Larsson 提交于
Add sparc support by using platform_get_irq instead of platform_get_resource. There are no platform resources of type IORESOURCE_IRQ for sparc, but platform_get_irq works for sparc. In the non-sparc case platform_get_irq internally uses platform_get_resource. Signed-off-by: NAndreas Larsson <andreas@gaisler.com> Acked-by: NPeter Korsgaard <jacmet@sunsite.dk> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
- 16 11月, 2012 14 次提交
-
-
由 Shubhrajyoti D 提交于
Currently we just queue the transfer and release the qos constraints, however we do not wait for the transfer to complete to release the constraint. Move the remove constraint after the bus busy as we are sure that the transfers are completed by then. Acked-by: NJean Pihet <j-pihet@ti.com> Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Maxime Ripard 提交于
This will allow to add the 3 Nuvoton NAU7802 ADCs and the NXP PCA9555 GPIO expander eventually. Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com> Acked-by: NShawn Guo <shawn.guo@linaro.org> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Daniel Kurtz 提交于
Commit "i2c-s3c2410: Add HDMIPHY quirk for S3C2440" added support for HDMIPHY with some special handling in s3c24xx_i2c_set_master: "due to unknown reason (probably HW bug in HDMIPHY and/or the controller) a transfer fails to finish. The controller hangs after sending the last byte, the workaround for this bug is resetting the controller after each transfer" The "unknown reason" was that the proper sequence for generating a STOP condition wasn't being followed as per the datasheet. Since this is fixed by "PATCH: i2c-s3c2410: do not generate STOP for QUIRK_HDMIPHY buses", remove the special handling. Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org> Signed-off-by: NNaveen Krishna Chatradhi <ch.naveen@samsung.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Daniel Kurtz 提交于
Usually, the i2c controller has finished emitting the i2c STOP before the driver reaches the bus idle polling loop. Optimize for this most common case by reading IICSTAT first and potentially skipping the loop. If the cpu is faster than the hardware, we wait for bus idle in a polling loop. However, since the duration of one iteration of the loop is dependent on cpu freq, and this i2c IP is used on many different systems, use a time based loop timeout (5 ms). We would like very low latencies to detect bus idle for the normal 'fast' case. However, if a device is slow to release the bus for some reason, it could hold off the STOP generation for up to several milliseconds. Rapidly polling for bus idle would seriously load the CPU while waiting for it to release the bus. So, use a partial exponential backoff as a compromise between idle detection latency and cpu load. Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org> Signed-off-by: NNaveen Krishna Chatradhi <ch.naveen@samsung.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Daniel Kurtz 提交于
The datasheet says that the STOP sequence should be: 1) I2CSTAT.5 = 0 - Clear BUSY (or 'generate STOP') 2) I2CCON.4 = 0 - Clear IRQPEND 3) Wait until the stop condition takes effect. 4*) I2CSTAT.4 = 0 - Clear TXRXEN Where, step "4*" is only for buses with the "HDMIPHY" quirk. However, after much experimentation, it appears that: a) normal buses automatically clear BUSY and transition from Master->Slave when they complete generating a STOP condition. Therefore, step (3) can be done in doxfer() by polling I2CCON.4 after starting the STOP generation here. b) HDMIPHY bus does neither, so there is no way to do step 3. There is no indication when this bus has finished generating STOP. In fact, we have found that as soon as the IRQPEND bit is cleared in step 2, the HDMIPHY bus generates the STOP condition, and then immediately starts transferring another data byte, even though the bus is supposedly stopped. This is presumably because the bus is still in "Master" mode, and its BUSY bit is still set. To avoid these extra post-STOP transactions on HDMI phy devices, we just disable Serial Output on the bus (I2CSTAT.4 = 0) directly, instead of first generating a proper STOP condition. This should float SDA & SCK terminating the transfer. Subsequent transfers start with a proper START condition, and proceed normally. The HDMIPHY bus is an internal bus that always has exactly two devices, the host as Master and the HDMIPHY device as the slave. Skipping the STOP condition has been tested on this bus and works. Also, since we disable the bus directly from the isr, we can skip the bus idle polling loop at the end of doxfer(). Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org> Signed-off-by: NNaveen Krishna Chatradhi <ch.naveen@samsung.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Daniel Kurtz 提交于
We probably don't want to change I2C frequency while a transfer is in progress. The current implementation grabs a spinlock, but that only protected the writes to IICCON when starting a message, it didn't protect against clock changes in the middle of a transaction. Note: The i2c-core already grabs the adapter lock before calling s3c24xx_i2c_doxfer(), which ensures that only one caller is issuing a xfer at a time. This means it is not necessary to disable interrupts (spin_lock_irqsave) when changing frequencies, since there won't be any i2c interrupts if there is no on-going xfer. Lastly, i2c_lock_adapter() may cause the cpufreq_transition to sleep if if a xfer is in progress, but this is ok since cpufreq notifiers are called in a kernel thread, and there are already cases where it could sleep, such as when using i2c to update the output of a voltage regulator. Note: the cpufreq part of this change has no functional affect on exynos, where the i2c clock is independent of the cpufreq. But, there is a slight perfomance boost since we no longer need to lock/unlock an additional spinlock. Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org> Signed-off-by: NNaveen Krishna Chatradhi <ch.naveen@samsung.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Tomasz Figa 提交于
This patch adds support for pin configuration using pinctrl subsystem to the i2c-s3c2410 driver. Signed-off-by: NTomasz Figa <t.figa@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Mark Brown 提交于
A small code saving and less error handling to worry about. Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Mark Brown 提交于
Use the PM_SLEEP ifdef for system suspend and resume. This is partly in preparation for adding runtime operations and partly because a user may in theory choose to enable runtime suspend but not system suspend. Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Reviewed-by: NShubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Maxime Ripard 提交于
Allow the i2c-mux-gpio to be used by a device tree enabled device. The bindings are inspired by the one found in the i2c-mux-pinctrl driver. Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: NStephen Warren <swarren@nvidia.com> Acked-by: NPeter Korsgaard <peter.korsgaard@barco.com> [wsa: fixed some whitespace] Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Shinya Kuribayashi 提交于
Ensure that any of preceding register write operations to the I2C hardware block reached the module, and the write data is reflected in the registers, before leaving the interrupt handler. Otherwise, we'll suffer from spurious WAIT interrupts that lead to 'Transfer request timed out' message, and the transaction failed. Reported-by: NTeppei Kamijou <teppei.kamijou.yb@renesas.com> Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi.px@renesas.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Shinya Kuribayashi 提交于
On newer SH-/R-Mobile SoCs, a clock supply to the I2C hardware block, which is used to generate the SCL clock output, is getting faster than before, while on the other hand, the SCL clock control registers, ICCH and ICCL, stay unchanged in 9-bit-wide (8+1). On such silicons, the internal SCL clock counter gets incremented every 2 clocks of the operating clock. This patch makes it configurable through platform data. Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi.px@renesas.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Shinya Kuribayashi 提交于
ICCH/ICCL values is supposed to be calculated/optimized to strictly meet the timing specs required by the I2C standard. The resulting I2C bus speed does not matter at all, if it's less than 100 or 400 kHz. With this change, sh_mobile_i2c_icch() is virtually identical to sh_mobile_i2c_iccl(), but they're providing good descriptions of SH-/R-Mobile I2C hardware spec, and I'd leave them as separated. Also fix a typo in the comment, print icch/iccl values at probe, etc. Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi.px@renesas.com> [wsa: squashed two patches for bisectability] Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Shinya Kuribayashi 提交于
Currently SCL clock parameters (ICCH/ICCL) are calculated in activate_ch(), which gets called every time sh_mobile_i2c_xfer() is processed, while each I2C bus speed is system-defined and in general those parameters do not have to be updated over I2C transactions. The only reason I could see having it transaction-time is to adjust ICCH/ICCL values according to the operating frequency of the I2C hardware block, in the face of DFS (Dynamic Frequency Scaling). However, this won't be necessary. The operating frequency of the I2C hardware block can change _even_ in the middle of I2C transactions. There is no way to prevent it from happening, and I2C hardware block can work with such dynamic frequency change, of course. Another is that ICCH/ICCL clock parameters optimized for the faster operating frequency, can also be applied to the slower operating frequency, as long as slave devices work. However, the converse is not true. It would violate SCL timing specs of the I2C standard. What we can do now is to calculate the ICCH/ICCL clock parameters according to the fastest operating clock of the I2C hardware block. And if that's the case, that calculation should be done just once at driver-module-init time. This patch moves ICCH/ICCL calculating part from activate_ch() into sh_mobile_i2c_init(), and call it from sh_mobile_i2c_probe(). Note that sh_mobile_i2c_init() just prepares clock parameters using the clock rate and platform data provided, but does _not_ make any hardware I/O accesses. We don't have to care about run-time PM maintenance here. Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi.px@renesas.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
- 15 11月, 2012 11 次提交
-
-
由 Wolfram Sang 提交于
Acked-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NWolfram Sang <wolfram@the-dreams.de>
-
由 Shubhrajyoti D 提交于
Currently after the reset the sysc is written with hardcoded values. The patch reads the sysc register and writes back the same value after reset. - Some unnecessary rev checks can be optimised. - Also due to whatever reason the hwmod flags are changed we will not reset the values. - In some of the cases the minor values of the 2430 register is different(0x37) in that case the autoidle setting may be missed. Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Shubhrajyoti D 提交于
Currently the restore is done based on the flag OMAP_I2C_FLAG_RESET_REGS_POSTIDLE. This helps the following - The driver is always capable of restoring regardless of the off mode support being there or not. - While testing omap2430 it is found that in case of certain error paths (timeout) a reset is done. However the restore never happens as it is dependent on the POSTIDLE flag. The other option would be to call a restore in the reset case. As there are only a few registers to be restored the penalty in the idle case should not be much. Reviewed-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Shubhrajyoti D 提交于
Implement reset as a separate function. This will enable us to make sure that we don't do the calculation again on every transfer. Also at probe the reset is not added as the hwmod is doing that for us. Reviewed-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Shubhrajyoti D 提交于
re-factor omap_i2c_init() so that we can re-use it for resume. While at it also remove the bufstate variable as we write it in omap_i2c_resize_fifo for every transfer. Reviewed-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Shubhrajyoti D 提交于
The commit [i2c: omap: use revision check for OMAP_I2C_FLAG_APPLY_ERRATA_I207] uses the revision id instead of the flag. So the flag can be safely removed. Reviewed-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Shubhrajyoti D 提交于
The dtrev is used only for the comments. Remove the same and use the scheme instead to know if it is version2. Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com> Reviewed-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Shubhrajyoti D 提交于
The errata i207 is enabled for 2430 and 3xxx. Use the revision check to enable the erratum instead. Reviewed-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Shubhrajyoti D 提交于
The revision register on OMAP4 is a 16-bit lo and a 16-bit hi. Currently the driver reads only the lower 8-bits. Fix the same by preventing the truncating of the rev register for OMAP4. Also use the scheme bit ie bit-14 of the hi register to know if it is OMAP_I2C_IP_VERSION_2. On platforms previous to OMAP4 the offset 0x04 is IE register whose bit-14 reset value is 0, the code uses the same to its advantage. Also since the omap_i2c_read_reg uses reg_map_ip_* a raw_readw is done to fetch the revision register. The dev->regs is populated after reading the rev_hi. A NULL check has been added in the resume handler to prevent the access before the setting of the regs. Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com> Reviewed-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Sebastien Guiriec 提交于
Some GPIO expanders need some early pin control muxing. Due to legacy boards sometimes the driver uses subsys_initcall instead of module_init. This patch takes advantage of defer probe feature and pin control in order to wait until pin control probing before GPIO driver probing. It has been tested on OMAP5 board with TCA6424 driver. Signed-off-by: NSebastien Guiriec <s-guiriec@ti.com> Acked-by: NShubhrajyoti D <shubhrajyoti@ti.com> Reviewed-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Felipe Balbi 提交于
if we allow compiler reorder our writes, we could fall into a situation where dev->buf_len is reset for no apparent reason. This bug was found with a simple script which would transfer data to an i2c client from 1 to 1024 bytes (a simple for loop), when we got to transfer sizes bigger than the fifo size, dev->buf_len was reset to zero before we had an oportunity to handle XDR Interrupt. Because dev->buf_len was zero, we entered omap_i2c_transmit_data() to transfer zero bytes, which would mean we would just silently exit omap_i2c_transmit_data() without actually writing anything to DATA register. That would cause XDR IRQ to trigger forever and we would never transfer the remaining bytes. After adding the memory barrier, we also drop resetting dev->buf_len to zero in omap_i2c_xfer_msg() because both omap_i2c_transmit_data() and omap_i2c_receive_data() will act until dev->buf_len reaches zero, rendering the other write in omap_i2c_xfer_msg() redundant. This patch has been tested with pandaboard for a few iterations of the script mentioned above. Signed-off-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
- 14 11月, 2012 3 次提交
-
-
由 Paul Walmsley 提交于
This reverts commit 3db11fef (ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints). This commit causes I2C timeouts to appear on several OMAP3430/3530-based boards: http://marc.info/?l=linux-arm-kernel&m=135071372426971&w=2 http://marc.info/?l=linux-arm-kernel&m=135067558415214&w=2 http://marc.info/?l=linux-arm-kernel&m=135216013608196&w=2 and appears to have been sent for merging before one of its prerequisites was merged: http://marc.info/?l=linux-arm-kernel&m=135219411617621&w=2Signed-off-by: NPaul Walmsley <paul@pwsan.com> Acked-by: NJean Pihet <j-pihet@ti.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Ludovic Desroches 提交于
The driver claims to support SMBus quick command but it was not the case. This patch fixes this issue. Without it, i2cdetect finds imaginary devices. And with some IP versions, trying to send 0 byte can cause issue when writing data to an EEPROM. Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com> Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> [wsa: improved the commit message] Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Bo Shen 提交于
When having multiple i2c-gpio nodes, the name for each is same. So add the patch to fix it. The adap->name printing information was added by myself without this patch the log information is as following ---<8--- adap->name = i2c-gpio-1 i2c-gpio i2c.2: using pins 30 (SDA) and 31 (SCL) adap->name = i2c-gpio-1 i2c-gpio i2c.3: using pins 64 (SDA) and 65 (SCL) --->8--- with this patch, the log information is as following ---<8--- adap->name = i2c.2 i2c-gpio i2c.2: using pins 30 (SDA) and 31 (SCL) adap->name = i2c.3 i2c-gpio i2c.3: using pins 64 (SDA) and 65 (SCL) --->8--- Signed-off-by: NBo Shen <voice.shen@atmel.com> Reviewed-by: NStephen Warren <swarren@nvidia.com> [wsa: minor fixes to the commit mesage] Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
- 13 11月, 2012 4 次提交
-
-
由 Thierry Reding 提交于
Replacing the devm_request_mem_region() and devm_ioremap_nocache() calls by a single call to devm_request_and_ioremap() simplifies the code. Signed-off-by: NThierry Reding <thierry.reding@avionic-design.de> Acked-by: NJean Delvare <khali@linux-fr.org> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Wolfram Sang 提交于
Give the driver struct a name according to the 'standard' to fix: WARNING: vmlinux.o(.data+0x11798): Section mismatch in reference from the variable rcar_i2c_drv to the function .devinit.text:rcar_i2c_probe() ... WARNING: vmlinux.o(.data+0x1179c): Section mismatch in reference from the variable rcar_i2c_drv to the function .devexit.text:rcar_i2c_remove() Reported-by: NSimon Horman <horms@verge.net.au> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
-
由 Kuninori Morimoto 提交于
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Chuansheng Liu 提交于
The return value of wait_for_completion_timeout() is always >= 0 with unsigned int type. So the condition "ret < 0" or "ret >= 0" is pointless. Signed-off-by: Nliu chuansheng <chuansheng.liu@intel.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
- 11 11月, 2012 3 次提交
-
-
由 Linus Torvalds 提交于
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net由 Linus Torvalds 提交于
Pull networking fixes from David Miller: "Bug fixes galore, mostly in drivers as is often the case: 1) USB gadget and cdc_eem drivers need adjustments to their frame size lengths in order to handle VLANs correctly. From Ian Coolidge. 2) TIPC and several network drivers erroneously call tasklet_disable before tasklet_kill, fix from Xiaotian Feng. 3) r8169 driver needs to apply the WOL suspend quirk to more chipsets, fix from Cyril Brulebois. 4) Fix multicast filters on RTL_GIGA_MAC_VER_35 r8169 chips, from Nathan Walp. 5) FDB netlink dumps should use RTM_NEWNEIGH as the message type, not zero. From John Fastabend. 6) Fix smsc95xx tx checksum offload on big-endian, from Steve Glendinning. 7) __inet_diag_dump() needs to repsect and report the error value returned from inet_diag_lock_handler() rather than ignore it. Otherwise if an inet diag handler is not available for a particular protocol, we essentially report success instead of giving an error indication. Fix from Cyrill Gorcunov. 8) When the QFQ packet scheduler sees TSO/GSO packets it does not handle things properly, and in fact ends up corrupting it's datastructures as well as mis-schedule packets. Fix from Paolo Valente. 9) Fix oopser in skb_loop_sk(), from Eric Leblond. 10) CXGB4 passes partially uninitialized datastructures in to FW commands, fix from Vipul Pandya. 11) When we send unsolicited ipv6 neighbour advertisements, we should send them to the link-local allnodes multicast address, as per RFC4861. Fix from Hannes Frederic Sowa. 12) There is some kind of bug in the usbnet's kevent deferral mechanism, but more immediately when it triggers an uncontrolled stream of kernel messages spam the log. Rate limit the error log message triggered when this problem occurs, as sending thousands of error messages into the kernel log doesn't help matters at all, and in fact makes further diagnosis more difficult. From Steve Glendinning. 13) Fix gianfar restore from hibernation, from Wang Dongsheng. 14) The netlink message attribute sizes are wrong in the ipv6 GRE driver, it was using the size of ipv4 addresses instead of ipv6 ones :-) Fix from Nicolas Dichtel." * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: gre6: fix rtnl dump messages gianfar: ethernet vanishes after restoring from hibernation usbnet: ratelimit kevent may have been dropped warnings ipv6: send unsolicited neighbour advertisements to all-nodes net: usb: cdc_eem: Fix rx skb allocation for 802.1Q VLANs usb: gadget: g_ether: fix frame size check for 802.1Q cxgb4: Fix initialization of SGE_CONTROL register isdn: Make CONFIG_ISDN depend on CONFIG_NETDEVICES cxgb4: Initialize data structures before using. af-packet: fix oops when socket is not present pkt_sched: enable QFQ to support TSO/GSO net: inet_diag -- Return error code if protocol handler is missed net: bnx2x: Fix typo in bnx2x driver smsc95xx: fix tx checksum offload for big endian rtnetlink: Use nlmsg type RTM_NEWNEIGH from dflt fdb dump ptp: update adjfreq callback description r8169: allow multicast packets on sub-8168f chipset. r8169: Fix WoL on RTL8168d/8111d. drivers/net: use tasklet_kill in device remove/close process tipc: do not use tasklet_disable before tasklet_kill
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc由 Linus Torvalds 提交于
Pull sparc fixes from David Miller: "Several build/bug fixes for sparc, including: 1) Configuring a mix of static vs. modular sparc64 crypto modules didn't work, remove an ill-conceived attempt to only have to build the device match table for these drivers once to fix the problem. Reported by Meelis Roos. 2) Make the montgomery multiple/square and mpmul instructions actually usable in 32-bit tasks. Essentially this involves providing 32-bit userspace with a way to use a 64-bit stack when it needs to. 3) Our sparc64 atomic backoffs don't yield cpu strands properly on Niagara chips. Use pause instruction when available to achieve this, otherwise use a benign instruction we know blocks the strand for some time. 4) Wire up kcmp 5) Fix the build of various drivers by removing the unnecessary blocking of OF_GPIO when SPARC. 6) Fix unintended regression wherein of_address_to_resource stopped being provided. Fix from Andreas Larsson. 7) Fix NULL dereference in leon_handle_ext_irq(), also from Andreas Larsson." * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc: sparc64: Fix build with mix of modular vs. non-modular crypto drivers. sparc: Support atomic64_dec_if_positive properly. of/address: sparc: Declare of_address_to_resource() as an extern function for sparc again sparc32, leon: Check for existent irq_map entry in leon_handle_ext_irq sparc: Add sparc support for platform_get_irq() sparc: Allow OF_GPIO on sparc. qlogicpti: Fix build warning. sparc: Wire up sys_kcmp. sparc64: Improvde documentation and readability of atomic backoff code. sparc64: Use pause instruction when available. sparc64: Fix cpu strand yielding. sparc64: Make montmul/montsqr/mpmul usable in 32-bit threads.
-
- 10 11月, 2012 3 次提交
-
-
git://git.samba.org/sfrench/cifs-2.6由 Linus Torvalds 提交于
Pull cifs fixes from Jeff Layton. * 'for-linus' of git://git.samba.org/sfrench/cifs-2.6: cifs: Do not lookup hashed negative dentry in cifs_atomic_open cifs: fix potential buffer overrun in cifs.idmap handling code
-
git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64由 Linus Torvalds 提交于
Pull arm64 fixes from Catalin Marinas: - correct argument type (pgprot_t) when calling __ioremap() - PCI_IOBASE virtual address change - use architected event for CPU cycle counter - fix ELF core dumping - select CONFIG_ARCH_WANT_COMPAT_IPC_PARSE_VERSION - missing completion for secondary CPU boot - booting on systems with all memory beyond 4GB * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64: arm64: mm: fix booting on systems with no memory below 4GB arm64: smp: add missing completion for secondary boot arm64: compat: select CONFIG_ARCH_WANT_COMPAT_IPC_PARSE_VERSION arm64: elf: fix core dumping definitions for GP and FP registers arm64: perf: use architected event for CPU cycle counter arm64: Move PCI_IOBASE closer to MODULES_VADDR arm64: Use pgprot_t as the last argument when invoking __ioremap()
-
由 Linus Torvalds 提交于
Merge tag 'stable/for-linus-3.7-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen Pull Xen fixes from Konrad Rzeszutek Wilk: "There are three ARM compile fixes (we forgot to export certain functions and if the drivers are built as an module - we go belly-up). There is also an mismatch of irq_enter() / exit_idle() calls sequence which were fixed some time ago in other piece of codes, but failed to appear in the Xen code. Lastly a fix for to help in the field with troubleshooting in case we cannot get the appropriate parameter and also fallback code when working with very old hypervisors." Bug-fixes: - Fix compile issues on ARM. - Fix hypercall fallback code for old hypervisors. - Print out which HVM parameter failed if it fails. - Fix idle notifier call after irq_enter. * tag 'stable/for-linus-3.7-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen: xen/arm: Fix compile errors when drivers are compiled as modules (export more). xen/arm: Fix compile errors when drivers are compiled as modules. xen/generic: Disable fallback build on ARM. xen/events: fix RCU warning, or Call idle notifier after irq_enter() xen/hvm: If we fail to fetch an HVM parameter print out which flag it is. xen/hypercall: fix hypercall fallback code for very old hypervisors
-