[RFC] background zero-set page for device
There was some discussion to create zero-set pages in background like this: https://lkml.org/lkml/2004/10/30/73 I'm understand that it is not good for performance. But I think it can help for a device in my platform. I'm sorry I can't tell what it is. But the device needs many zero-set pages, up to several MB, so that device driver has a loop to calls alloc_page, memset(p, 0, PAGE_SIZE) and cache flush And the device uses the pages and returns it to kernel. Kernel reads data in the page. In this case, memset(0) must be done. I think, if memset(0) is done at idle time, it can remove memset calling of ddk. Is there any device that needs many zero-set pages? Can backgound zero-setting page be good for the device? -- Thanks, Gioh Kim -- 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 v2 03/10] power: charger-manager: Remove deprecated function, cm_notify_event().
> > cm_notify_event() is introduced to get event associated with battery status > externally, but no one had been used. Moreover it makes charger manager > driver more complicated. This patch tries to drop the function and all data > related to simplify the driver. > > Signed-off-by: Jonghwa Lee You are not just removing cm_notify_event() and its related. You are hereby removing the much of software charger control and suspend-related operations. Could you please be more specific on why? (many of such features are to comply with operators' requirements) (Or we may meet next Monday for some discussions :) ) > --- > .../bindings/power_supply/charger-manager.txt |1 - > drivers/power/charger-manager.c| 196 > +--- > include/linux/power/charger-manager.h | 19 +- > 3 files changed, 8 insertions(+), 208 deletions(-) >
Re: [PATCH 4/4] PM: Eliminate CONFIG_PM_RUNTIME
On 19 December 2014 at 03:03, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Having switched over all of the users of CONFIG_PM_RUNTIME to use > CONFIG_PM directly, turn the latter into a user-selectable option > and drop the former entirely from the tree. > > Signed-off-by: Rafael J. Wysocki I am impressed , in this short period of time we managed to remove all *PM_RUNTIME" configurations! Great work! Reviewed-by: Ulf Hansson > --- > arch/arm/configs/ape6evm_defconfig |2 +- > arch/arm/configs/armadillo800eva_defconfig |2 +- > arch/arm/configs/bcm_defconfig |2 +- > arch/arm/configs/bockw_defconfig |2 +- > arch/arm/configs/davinci_all_defconfig |2 +- > arch/arm/configs/exynos_defconfig |2 +- > arch/arm/configs/ezx_defconfig |2 +- > arch/arm/configs/hisi_defconfig|2 +- > arch/arm/configs/imote2_defconfig |2 +- > arch/arm/configs/imx_v6_v7_defconfig |2 +- > arch/arm/configs/keystone_defconfig|2 +- > arch/arm/configs/kzm9g_defconfig |2 +- > arch/arm/configs/lager_defconfig |2 +- > arch/arm/configs/mackerel_defconfig|2 +- > arch/arm/configs/marzen_defconfig |2 +- > arch/arm/configs/omap1_defconfig |2 +- > arch/arm/configs/prima2_defconfig |2 +- > arch/arm/configs/sama5_defconfig |2 +- > arch/arm/configs/shmobile_defconfig|2 +- > arch/arm/configs/sunxi_defconfig |2 +- > arch/arm/configs/tegra_defconfig |2 +- > arch/arm/configs/u8500_defconfig |2 +- > arch/arm/configs/vt8500_v6_v7_defconfig|2 +- > arch/arm/mach-omap2/Kconfig|6 +++--- > arch/mips/configs/db1xxx_defconfig |2 +- > arch/mips/configs/lemote2f_defconfig |2 +- > arch/mips/configs/loongson3_defconfig |2 +- > arch/mips/configs/nlm_xlp_defconfig|2 +- > arch/mips/configs/nlm_xlr_defconfig|2 +- > arch/powerpc/configs/ps3_defconfig |2 +- > arch/sh/Kconfig|2 +- > arch/sh/configs/apsh4ad0a_defconfig|2 +- > arch/sh/configs/sdk7786_defconfig |2 +- > drivers/usb/host/isp1760-hcd.c |2 +- > drivers/usb/host/oxu210hp-hcd.c|2 +- > include/linux/devfreq.h|2 +- > kernel/power/Kconfig | 16 ++-- > 37 files changed, 44 insertions(+), 48 deletions(-) > > Index: linux-pm/arch/arm/configs/ape6evm_defconfig > === > --- linux-pm.orig/arch/arm/configs/ape6evm_defconfig > +++ linux-pm/arch/arm/configs/ape6evm_defconfig > @@ -33,7 +33,7 @@ CONFIG_ARM_APPENDED_DTB=y > CONFIG_VFP=y > CONFIG_NEON=y > CONFIG_BINFMT_MISC=y > -CONFIG_PM_RUNTIME=y > +CONFIG_PM=y > CONFIG_NET=y > CONFIG_PACKET=y > CONFIG_UNIX=y > Index: linux-pm/arch/arm/configs/armadillo800eva_defconfig > === > --- linux-pm.orig/arch/arm/configs/armadillo800eva_defconfig > +++ linux-pm/arch/arm/configs/armadillo800eva_defconfig > @@ -43,7 +43,7 @@ CONFIG_KEXEC=y > CONFIG_VFP=y > CONFIG_NEON=y > # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set > -CONFIG_PM_RUNTIME=y > +CONFIG_PM=y > CONFIG_NET=y > CONFIG_PACKET=y > CONFIG_UNIX=y > Index: linux-pm/arch/arm/configs/bcm_defconfig > === > --- linux-pm.orig/arch/arm/configs/bcm_defconfig > +++ linux-pm/arch/arm/configs/bcm_defconfig > @@ -39,7 +39,7 @@ CONFIG_CPU_IDLE=y > CONFIG_VFP=y > CONFIG_NEON=y > # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set > -CONFIG_PM_RUNTIME=y > +CONFIG_PM=y > CONFIG_NET=y > CONFIG_PACKET=y > CONFIG_PACKET_DIAG=y > Index: linux-pm/arch/arm/configs/bockw_defconfig > === > --- linux-pm.orig/arch/arm/configs/bockw_defconfig > +++ linux-pm/arch/arm/configs/bockw_defconfig > @@ -29,7 +29,7 @@ CONFIG_ZBOOT_ROM_BSS=0x0 > CONFIG_ARM_APPENDED_DTB=y > CONFIG_VFP=y > # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set > -CONFIG_PM_RUNTIME=y > +CONFIG_PM=y > CONFIG_NET=y > CONFIG_PACKET=y > CONFIG_UNIX=y > Index: linux-pm/arch/arm/configs/davinci_all_defconfig > === > --- linux-pm.orig/arch/arm/configs/davinci_all_defconfig > +++ linux-pm/arch/arm/configs/davinci_all_defconfig > @@ -49,7 +49,7 @@ CONFIG_CPU_FREQ_GOV_PERFORMANCE=m > CONFIG_CPU_FREQ_GOV_POWERSAVE=m > CONFIG_CPU_FREQ_GOV_ONDEMAND=m > CONFIG_CPU_IDLE=y > -CONFIG_PM_RUNTIME=y > +CONFIG_PM=y > CONFIG_NET=y > CONFIG_PACKET=y > CONFIG_UNIX=y > Index: linux-pm/arch/arm/configs/exynos_defconfig > === > ---
Re: [PATCH RESEND v2 02/10] power: charger-manager: Use power_supply_changed() not private uevent.
> > Whenever battery status is changed, charger manager tries to trigger uevent > through private interface. This patch modifies it to use > power_supply_changed() > since it belongs to power supply subsystem. > > Signed-off-by: Jonghwa Lee The original uevent_notify() has two additional mechanisms: C1. Save events in suspend-again context and show them up at wakeup. C2. If the new event is a duplicated event, ignore it. Questions: Q1. Have you checked if C1 is met with the modification? Besides, have you made it sure that the modification won't change the behavior of suspend-again context? (whether "theoretical" or "experimental") Q2. Do you still support C2? For example, if we have notifited the user that we are charging 30 seconds ago, we should never bother the user with another message that declares that it is charging unless we have notified that we are not charging since then. Cheers, MyungJoo. > --- > drivers/power/charger-manager.c | 91 > +-- > 1 file changed, 11 insertions(+), 80 deletions(-) >
Re: [PATCH RFC v2 00/14] Add support for i.MX MIPI DSI DRM driver
Hi Andy, On 12/19/2014 02:33 PM, Andy Yan wrote: Hi Liu Ying: I foud Rockchip RK618 (a mfd function device with mipi dsi，lvds transmitter、HDMI TX、and audio codec，and controlled by the SOC from i2c ) have the same register layout with your i.MX MIPI DSI，which means RK618 MIPI DSI also have the Synopsys compatible DSI IP。So Would you please make this drives more platform independent？ I may try to place the Synopsys DesignWare MIPI DSI driver in the drm/bridge directory and make it as less platform-dependant as possible. I have no access to the Rockchip RK618 chip and it's reference menu. You probably may add the Rockchip part support later. Regards, Liu Ying At 2014-12-18 15:11:22, "Liu Ying" wrote: Hi, This series addressed almost all comments from Thierry Redding and Russell on v1. This series adds support for i.MX MIPI DSI DRM driver. Currently, the MIPI DSI driver only supports the burst with sync pulse mode. This series also includes a DRM panel driver for the Truly TFT480800-16-E panel which is driven by the Himax HX8369A driver IC. The driver IC data sheet could be found at [1]. As mentioned by the data sheet, the driver IC supports several interface modes. Currently, the DRM panel driver only supports the MIPI DSI video mode. New interface modes could be added later(perhaps, just like the way the DRM simple panel driver supports both MIPI DSI interface panels and simple(parallel) interface panels). The MIPI DSI feature is tested on i.MX6Q SabreSD board and i.MX6DL SabreSD board. The MIPI DSI display could be enabled directly on i.MX6Q SabreSD board after applying this series, because the 26.4MHz pixel clock the panel requires could be derived from the IPU HSP clock(264MHz) with an integer divider. On i.MX6DL SabreSD board, we need to manually disable the LVDS and HDMI displays in the device tree blob, since the i.MX6DL IPU HSP clock is 198MHz at present, which makes the pixel clock share the PLL5 video clock source with the LVDS and HDMI, thus, the panel cannot get the pixel clock rate it wants. Patch 01/15 is needed to get a precise pixel clock rate(26.4MHz) from the PLL5 video clock. If we don't have this patch, the pixel clock rate is about 20MHz, which causes a horitonal shift on the display image. This series can be applied on the drm-next branch. [1] http://www.allshore.com/pdf/Himax_HX8369-A.pdf Liu Ying (14): clk: divider: Correct parent clk round rate if no bestdiv is normally found of: Add vendor prefix for Himax Technologies Inc. of: Add vendor prefix for Truly Semiconductors Limited ARM: imx6q: Add GPR3 MIPI muxing control register field shift bits definition ARM: imx6q: clk: Add the video_27m clock ARM: dts: imx6qdl: Move existing MIPI DSI ports into a new 'ports' node drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format drm: imx: Add MIPI DSI host controller driver drm: panel: Add support for Himax HX8369A MIPI DSI panel ARM: dtsi: imx6qdl: Add support for MIPI DSI host controller ARM: dts: imx6qdl-sabresd: Add support for TRULY TFT480800-16-E MIPI DSI panel ARM: imx_v6_v7_defconfig: Cleanup for imx drm being moved out of staging ARM: imx_v6_v7_defconfig: Add support for MIPI DSI host controller ARM: imx_v6_v7_defconfig: Add support for Himax HX8369A panel .../devicetree/bindings/drm/imx/mipi_dsi.txt | 78 ++ .../devicetree/bindings/panel/himax,hx8369a.txt| 41 + .../devicetree/bindings/vendor-prefixes.txt|2 + arch/arm/boot/dts/imx6q.dtsi | 20 +- arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 20 + arch/arm/boot/dts/imx6qdl.dtsi | 30 +- arch/arm/configs/imx_v6_v7_defconfig | 17 +- arch/arm/mach-imx/clk-imx6q.c |1 + drivers/clk/clk-divider.c |3 +- drivers/gpu/drm/imx/Kconfig|6 + drivers/gpu/drm/imx/Makefile |1 + drivers/gpu/drm/imx/imx-mipi-dsi.c | 1056 drivers/gpu/drm/panel/Kconfig |5 + drivers/gpu/drm/panel/Makefile |1 + drivers/gpu/drm/panel/panel-himax-hx8369a.c| 573 +++ include/drm/drm_mipi_dsi.h | 14 + include/dt-bindings/clock/imx6qdl-clock.h |3 +- include/linux/mfd/syscon/imx6q-iomuxc-gpr.h|1 + 18 files changed, 1844 insertions(+), 28 deletions(-) create mode 100644 Documentation/devicetree/bindings/drm/imx/mipi_dsi.txt create mode 100644 Documentation/devicetree/bindings/panel/himax,hx8369a.txt create mode 100644 drivers/gpu/drm/imx/imx-mipi-dsi.c create mode 100644 drivers/gpu/drm/panel/panel-himax-hx8369a.c -- 2.1.0 ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line "unsubscribe
Re: [PATCHv7 2/3] kernel: add support for live patching
On Tue, 16 Dec 2014, Seth Jennings wrote: > This commit introduces code for the live patching core. It implements > an ftrace-based mechanism and kernel interface for doing live patching > of kernel and kernel module functions. > > It represents the greatest common functionality set between kpatch and > kgraft and can accept patches built using either method. > > This first version does not implement any consistency mechanism that > ensures that old and new code do not run together. In practice, ~90% of > CVEs are safe to apply in this way, since they simply add a conditional > check. However, any function change that can not execute safely with > the old version of the function can _not_ be safely applied in this > version. > > Signed-off-by: Seth Jennings > Signed-off-by: Josh Poimboeuf I have finally finished reviewing this as well. Reviewed-by: Jiri Kosina and Signed-off-by: Jiri Kosina for the changes I contributed. I'll wait a bit more to eventually gather more acks / review comments, and will then push it to git.kernel.org repository (with SUSE copyright added to livepatch.c) and have included in linux-next, as discussed before. Thanks! -- Jiri Kosina SUSE Labs -- 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 RFC v4 net-next 1/5] virtio_net: enable tx interrupt
On 2014/12/1 18:17, Jason Wang wrote:
On newer hosts that support delayed tx interrupts,
we probably don't have much to gain from orphaning
packets early.
Note: this might degrade performance for
hosts without event idx support.
Should be addressed by the next patch.
Cc: Rusty Russell
Cc: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Jason Wang
---
drivers/net/virtio_net.c | 132 +++
1 file changed, 88 insertions(+), 44 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index ec2a8b4..f68114e 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
static int xmit_skb(struct send_queue *sq, struct sk_buff *skb)
{
struct skb_vnet_hdr *hdr;
@@ -912,7 +951,9 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff
*skb)
sg_set_buf(sq->sg, hdr, hdr_len);
num_sg = skb_to_sgvec(skb, sq->sg + 1, 0, skb->len) + 1;
}
- return virtqueue_add_outbuf(sq->vq, sq->sg, num_sg, skb, GFP_ATOMIC);
+
+ return virtqueue_add_outbuf(sq->vq, sq->sg, num_sg, skb,
+ GFP_ATOMIC);
}
static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
@@ -924,8 +965,7 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct
net_device *dev)
struct netdev_queue *txq = netdev_get_tx_queue(dev, qnum);
bool kick = !skb->xmit_more;
- /* Free up any pending old buffers before queueing new ones. */
- free_old_xmit_skbs(sq);
I think there is no need to remove free_old_xmit_skbs here.
you could add free_old_xmit_skbs in tx_irq's napi func.
also could do this in start_xmit if you handle the race well.
I have done the same thing in ixgbe driver(free skb in ndo_start_xmit
and both in tx_irq's poll func), and it seems work well:)
I think there would be no so much interrupts in this way, also tx
interrupt coalesce is not needed.
+ virtqueue_disable_cb(sq->vq);
/* Try to transmit */
err = xmit_skb(sq, skb);
@@ -941,27 +981,19 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct
net_device *dev)
return NETDEV_TX_OK;
}
- /* Don't wait up for transmitted skbs to be freed. */
- skb_orphan(skb);
- nf_reset(skb);
-
/* Apparently nice girls don't return TX_BUSY; stop the queue
* before it gets out of hand. Naturally, this wastes entries. */
- if (sq->vq->num_free < 2+MAX_SKB_FRAGS) {
+ if (sq->vq->num_free < 2+MAX_SKB_FRAGS)
netif_stop_subqueue(dev, qnum);
- if (unlikely(!virtqueue_enable_cb_delayed(sq->vq))) {
- /* More just got used, free them then recheck. */
- free_old_xmit_skbs(sq);
- if (sq->vq->num_free >= 2+MAX_SKB_FRAGS) {
- netif_start_subqueue(dev, qnum);
- virtqueue_disable_cb(sq->vq);
- }
- }
- }
if (kick || netif_xmit_stopped(txq))
virtqueue_kick(sq->vq);
+ if (unlikely(!virtqueue_enable_cb_delayed(sq->vq))) {
+ virtqueue_disable_cb(sq->vq);
+ napi_schedule(>napi);
+ }
+
return NETDEV_TX_OK;
}
@@ -1138,8 +1170,10 @@ static int virtnet_close(struct net_device *dev)
/* Make sure refill_work doesn't re-enable napi! */
cancel_delayed_work_sync(>refill);
- for (i = 0; i < vi->max_queue_pairs; i++)
+ for (i = 0; i < vi->max_queue_pairs; i++) {
napi_disable(>rq[i].napi);
+ napi_disable(>sq[i].napi);
+ }
return 0;
}
@@ -1452,8 +1486,10 @@ static void virtnet_free_queues(struct virtnet_info *vi)
{
int i;
- for (i = 0; i < vi->max_queue_pairs; i++)
+ for (i = 0; i < vi->max_queue_pairs; i++) {
netif_napi_del(>rq[i].napi);
+ netif_napi_del(>sq[i].napi);
+ }
kfree(vi->rq);
kfree(vi->sq);
--
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: [kpatch] [PATCH] livepatch v7: move x86 specific ftrace handler code to arch/x86
On Fri, 19 Dec 2014, Li Bin wrote: > The execution flow redirection related implemention in the livepatch > ftrace handler is depended on the specific architecture. This patch > introduces klp_arch_set_pc(like kgdb_arch_set_pc) interface to change > the pt_regs. > > Signed-off-by: Li Bin Good catch, thanks. Reviewed-by: Jiri Kosina -- Jiri Kosina SUSE Labs -- 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 v5 4/6] staging: fpga manager: add driver for socfpga fpga manager
On 12/18/2014 09:59 PM, atull wrote:
> On Thu, 18 Dec 2014, Michal Simek wrote:
>
> Hi Michal,
>
>>> +
>>> + /* Write out remaining non 32-bit chunks. */
>>> + switch (count) {
>>> + case 3:
>>> + socfpga_fpga_data_writel(priv, buffer_32[i++] & 0x00ff);
>>> + break;
>>> + case 2:
>>> + socfpga_fpga_data_writel(priv, buffer_32[i++] & 0x);
>>> + break;
>>> + case 1:
>>> + socfpga_fpga_data_writel(priv, buffer_32[i++] & 0x00ff);
>>> + break;
>>> + default:
>>> + /* This will never happen. */
>>
>> why not just return any error code here even if this can't happen.
>>
>
> OK. Will be in v6.
>
>>
>> add it to one line.
>>
>> The rest is looks good to me. I think this is good to go in.
>>
>> Acked-by: Michal Simek
>>
>> Thanks,
>> Michal
>>
>
> Thanks for the feedback. So patches 1-4 look good now?
Will look at them.
M
--
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/
DONATION
I Mark and my wife Cindy Hill of Missouri won a Jackpot we have decided to donate the sum of 900,000.00 USD to you. Contact us via our personal email. fill the following. 1.Name 2. Country 3.Sex Note that you have to contact my private email for more informations. Goodluck, Mrs Cindy Hill --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v2 01/10] power: charger-manager: Use thermal subsystem interface only to get temperature.
> > It drops the way of using power_supply interface to reference battery's > temperature. Then it tries to use thermal subsystem's only. This makes driver > more simple and also can remove ifdeferies. > > Signed-off-by: Jonghwa Lee Acked-by: MyungJoo Ham > --- > drivers/power/Kconfig |1 + > drivers/power/charger-manager.c | 113 > - > include/linux/power/charger-manager.h |3 +- > 3 files changed, 28 insertions(+), 89 deletions(-) >
Re: [PATCH v5 3/6] staging: fpga manager: framework core
On 12/18/2014 09:46 PM, atull wrote:
> On Thu, 18 Dec 2014, Michal Simek wrote:
>
>> Hi Alan,
>>
>> first of all - there are these kernel-doc warnings.
>>
>> Info(drivers/staging/fpga/fpga-mgr.c:37): Scanning doc for
>> fpga_mgr_low_level_state
>> Warning(drivers/staging/fpga/fpga-mgr.c:43): No description found for return
>> value of 'fpga_mgr_low_level_state'
>> Info(drivers/staging/fpga/fpga-mgr.c:51): Scanning doc for __fpga_mgr_reset
>> Warning(drivers/staging/fpga/fpga-mgr.c:55): No description found for return
>> value of '__fpga_mgr_reset'
>> Info(drivers/staging/fpga/fpga-mgr.c:69): Scanning doc for fpga_mgr_reset
>> Warning(drivers/staging/fpga/fpga-mgr.c:73): No description found for return
>> value of 'fpga_mgr_reset'
>> Info(drivers/staging/fpga/fpga-mgr.c:88): Scanning doc for
>> __fpga_mgr_stage_init
>> Warning(drivers/staging/fpga/fpga-mgr.c:92): No description found for return
>> value of '__fpga_mgr_stage_write_init'
>> Info(drivers/staging/fpga/fpga-mgr.c:108): Scanning doc for
>> __fpga_mgr_stage_write
>> Warning(drivers/staging/fpga/fpga-mgr.c:115): No description found for
>> return value of '__fpga_mgr_stage_write'
>> Info(drivers/staging/fpga/fpga-mgr.c:129): Scanning doc for
>> __fpga_mgr_stage_complete
>> Warning(drivers/staging/fpga/fpga-mgr.c:133): No description found for
>> return value of '__fpga_mgr_stage_write_complete'
>> Info(drivers/staging/fpga/fpga-mgr.c:151): Scanning doc for __fpga_mgr_write
>> Warning(drivers/staging/fpga/fpga-mgr.c:158): No description found for
>> return value of '__fpga_mgr_write'
>> Info(drivers/staging/fpga/fpga-mgr.c:173): Scanning doc for fpga_mgr_write
>> Warning(drivers/staging/fpga/fpga-mgr.c:179): No description found for
>> return value of 'fpga_mgr_write'
>> Info(drivers/staging/fpga/fpga-mgr.c:195): Scanning doc for
>> fpga_mgr_firmware_write
>> Warning(drivers/staging/fpga/fpga-mgr.c:204): No description found for
>> return value of 'fpga_mgr_firmware_write'
>> Info(drivers/staging/fpga/fpga-mgr.c:234): Scanning doc for fpga_mgr_name
>> Warning(drivers/staging/fpga/fpga-mgr.c:239): No description found for
>> return value of 'fpga_mgr_name'
>> Info(drivers/staging/fpga/fpga-mgr.c:414): Scanning doc for fpga_mgr_register
>> Warning(drivers/staging/fpga/fpga-mgr.c:423): No description found for
>> return value of 'fpga_mgr_register'
>> Info(drivers/staging/fpga/fpga-mgr.c:480): Scanning doc for fpga_mgr_remove
>> Warning(drivers/staging/fpga/fpga-mgr.c:484): No description found for
>> parameter 'pdev'
>> Warning(drivers/staging/fpga/fpga-mgr.c:484): Excess function parameter
>> 'dev' description in 'fpga_mgr_remove'
>>
>
> I see the warnings now. I wasn't using the '-v' option for kernel-doc.
> Fixed in v6.
>
>>> diff --git a/drivers/staging/fpga/Makefile b/drivers/staging/fpga/Makefile
>>> new file mode 100644
>>> index 000..ff6c677
>>> --- /dev/null
>>> +++ b/drivers/staging/fpga/Makefile
>>> @@ -0,0 +1,10 @@
>>> +#
>>> +# Makefile for the fpga framework and fpga manager drivers.
>>> +#
>>> +
>>> +fpga-mgr-core-y += fpga-mgr.o
>>
>> remove this line - it is unused.
>>
>
> OK
>
>>> +static int __init fpga_mgr_dev_init(void)
>>> +{
>>> + pr_info("FPGA Manager framework driver\n");
>>> +
>>> + fpga_mgr_class = class_create(THIS_MODULE, "fpga_manager");
>>> + if (IS_ERR(fpga_mgr_class))
>>> + return PTR_ERR(fpga_mgr_class);
>>> +
>>> + fpga_mgr_class->dev_groups = fpga_mgr_groups;
>>
>>
>> Write this here.
>>if (IS_ENABLED(CONFIG_FPGA_MGR_SYSFS)) {
>> fpga_mgr_class->dev_groups = fpga_mgr_groups;
>>}
>>
>> I have tested it and it is working just fine. You can compile this
>> driver with SYSFS=n
>> The whole code is built and config option just export it.
>> I think it is better than having #if there.
>>
>> Greg: Is there any problem with this solution?
>>
>
> I'm cool with this myself. I'll add in v6.
>
>> BTW: I have pushed my branch to zero day testing system to get better
>> coverage
>>
>
> Michal, I've already done that with each submission. Assuming you are
> referring to the kbuild test robot.
Yes, Kbuild test robot.
Thanks,
Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: rtl8192u: removed an unnecessary else statement
Karthik,
On Fri, Dec 19, 2014 at 10:16:18AM +0530, karthik nayak wrote:
>
> On 12/19/2014 04:08 AM, Jeremiah Mahler wrote:
> >Karthik,
> >
> >On Thu, Dec 18, 2014 at 02:50:11PM +0530, Karthik Nayak wrote:
> >>As per checkpatch warning, removed an unnecessary else statement
> >>proceeding an if statement with a return.
> >>
> >>Signed-off-by: Karthik Nayak
> >>---
> >> drivers/staging/rtl8192u/r8192U_dm.c | 16 +++-
> >> 1 file changed, 7 insertions(+), 9 deletions(-)
> >>
> >>diff --git a/drivers/staging/rtl8192u/r8192U_dm.c
> >>b/drivers/staging/rtl8192u/r8192U_dm.c
> >>index 936565d..b3b508c 100644
> >>--- a/drivers/staging/rtl8192u/r8192U_dm.c
> >>+++ b/drivers/staging/rtl8192u/r8192U_dm.c
> >>@@ -480,15 +480,13 @@ static void dm_bandwidth_autoswitch(struct net_device
> >>*dev)
> >>if(priv->CurrentChannelBW == HT_CHANNEL_WIDTH_20
> >> ||!priv->ieee80211->bandwidth_auto_switch.bautoswitch_enable){
> >>return;
> >>- }else{
> >>- if(priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz ==
> >>false){//If send packets in 40 Mhz in 20/40
> >>- if(priv->undecorated_smoothed_pwdb <=
> >>priv->ieee80211->bandwidth_auto_switch.threshold_40Mhzto20Mhz)
> >>-
> >>priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz = true;
> >>- }else{//in force send packets in 20 Mhz in 20/40
> >>- if(priv->undecorated_smoothed_pwdb >=
> >>priv->ieee80211->bandwidth_auto_switch.threshold_20Mhzto40Mhz)
> >>-
> >>priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz = false;
> >>-
> >>- }
> >>+ }
> >>+ if(priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz ==
> >>false){//If send packets in 40 Mhz in 20/40
> >>+ if(priv->undecorated_smoothed_pwdb <=
> >>priv->ieee80211->bandwidth_auto_switch.threshold_40Mhzto20Mhz)
> >>+ priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz
> >>= true;
> >>+ }else{//in force send packets in 20 Mhz in 20/40
> >>+ if(priv->undecorated_smoothed_pwdb >=
> >>priv->ieee80211->bandwidth_auto_switch.threshold_20Mhzto40Mhz)
> >>+ priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz
> >>= false;
> >>}
> >> } // dm_BandwidthAutoSwitch
> >[...]
> >
> >Wow, I don't think I have ever seen a file with so many checkpatch errors!
> >
> >Instead of only fixing one instance of one error I would fix all
> >instances of that type of error. Since the changes would be very
> >similar it should still be easy to review.
> >
> >You could even make a whole patch series with each patch fixing one type
> >of error. Although I would keep the series to just a few at first until
> >you are sure you are doing everything right.
> >
> Hello Jeremiah,
> I agree, there are a lot of errors, so I fixed a single issue.
> This is just to get used to checkpatch system.
> I can write patches to fix the other things, but I rather not.
> I hope you get the point.
> Regards
> Karthik Nayak
Starting small sounds like a good idea.
--
- Jeremiah Mahler
--
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: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' is set
Wu, Feng wrote on 2014-12-19: > > > Zhang, Yang Z wrote on 2014-12-19: >> Subject: RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' is >> set >> >> Wu, Feng wrote on 2014-12-19: >>> >>> >>> Zhang, Yang Z wrote on 2014-12-19: Subject: RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' is set Wu, Feng wrote on 2014-12-19: > > > Zhang, Yang Z wrote on 2014-12-19: >> Subject: RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' >> is set >> >> Wu, Feng wrote on 2014-12-19: >>> >>> >>> iommu-boun...@lists.linux-foundation.org wrote on >> mailto:iommu-boun...@lists.linux-foundation.org] On Behalf Of: Cc: io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; k...@vger.kernel.org Subject: RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' is set Paolo Bonzini wrote on 2014-12-18: > > > On 18/12/2014 04:14, Wu, Feng wrote: >> >> >> linux-kernel-ow...@vger.kernel.org wrote on mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Paolo: >>> x...@kernel.org; Gleb Natapov; Paolo Bonzini; >>> dw...@infradead.org; >>> joro-zlv9swrftaidnm+yrof...@public.gmane.org; Alex Williamson; >>> joro-zLv9SwRftAIdnm+Jiang Liu Cc: >>> io...@lists.linux-foundation.org; >>> linux-kernel-u79uwxl29ty76z2rm5m...@public.gmane.org; > KVM >> list; >>> Eric Auger Subject: Re: [v3 25/26] KVM: Suppress >>> posted-interrupt when 'SN' is set >>> >>> >>> >>> On 12/12/2014 16:14, Feng Wu wrote: Currently, we don't support urgent interrupt, all interrupts are recognized as non-urgent interrupt, so we cannot send posted-interrupt when 'SN' is set. >>> >>> Can this happen? If the vcpu is in guest mode, it cannot >>> have been scheduled out, and that's the only case when SN is set. >>> >>> Paolo >> >> Currently, the only place where SN is set is vCPU is >> preempted and If the vCPU is preempted, shouldn't the subsequent be ignored? What happens if a PI is occurs when vCPU is preempted? >>> >>> If a vCPU is preempted, the 'SN' bit is set, the subsequent >>> interrupts are suppressed for posting. >> >> I mean what happens if we don't set SN bit. From my point, if >> preempter already disabled the interrupt, it is ok to leave SN >> bit as zero. But if preempter enabled the interrupt, doesn't >> this mean he allow interrupt to happen? BTW, since there >> already has ON bit, so this means there only have one interrupt >> arrived at most and it doesn't hurt performance. Do we really need to >> set SN bit? > > > See this scenario: > vCPU0 is running on pCPU0 > --> vCPU0 is preempted by vCPU1 > --> Then vCPU1 is running on pCPU0 and vCPU0 is waiting for > --> schedule in runqueue > > If the we don't set SN for vCPU0, then all subsequent interrupts > for > vCPU0 is posted to vCPU1, this will consume hardware and > software The PI vector for vCPU1 is notification vector, but the PI vector for vCPU0 should be wakeup vector. Why vCPU1 will consume this PI event? >>> >>> Wakeup vector is only used for blocking case, when vCPU is >>> preempted and waiting in the runqueue, the NV is the notification vector. >> >> I see your point. But from performance point, if we can schedule the >> vCPU to another PCPU to handle the interrupt, it would helpful. But I >> remember current KVM will not schedule the vCPU in run queue (even >> though it got preempted) to another pCPU to run(Am I right?). So it may >> hard to do it. >> > > KVM is using the Linux scheduler, when the preempted vCPU (in > runqueue) is scheduled again depends on the scheduling algorithm > itself, I think it is a little hard for us to get involved. > > I think what you mentioned is a little like the urgent interrupt in VT-d PI > Spec. > For this kind of interrupts, if an interrupt is coming for an > preempted vCPU (waiting in the run queue), we need to schedule the > vCPU immediately. This is some real time things. And we don't support urgent > interrupt so far. Yes. IIRC, if we use two global vectors mechanism properly, there should no need to use hardware urgent interrupt mechanism. :) > > Thanks, > Feng > >>> >>> Thanks, >>> Feng >>> > efforts and in fact it is not needed at all. If SN is set for > vCPU0, VT-d hardware will not issue Notification Event for vCPU0 > when an interrupt is for it, but just setting the related PIR bit. > > Thanks, > Feng > >> >>> >>> Thanks, >>> Feng >>> >> waiting for the next scheduling in the runqueue. But I am >>
RE: [DISCUSSION] USB device remote wakeup is not working for S3 case
> There's a simple solution: Call device_set_wakeup_enable() for the device!
> You can do this from the command line by:
>
> echo auto >/sys/bus/usb/devices/.../power/control
>
> where the "..." is the pathname for your device.
>
Yes, this can enable auto-suspend for usb device like a mouse. And remote wakeup
does work for RPM because rpm suspend refers to the needs_remote_wakeup flag.
But this doesn't impact system level suspend. The correct thing is:
echo enabled >/sys/bus/usb/devices/.../power/wakeup
This will call device_set_wakeup_enable() for the device and should work. But
unfortunately it seems didn't work even the wakeup file shows "enabled" which
means the device is wakeup enabled(Tried on 3.16 & 3.18 kernel). This is a
different
issue, I will check.
> if (interface->desc.bInterfaceSubClass ==
> USB_INTERFACE_SUBCLASS_BOOT &&
> interface->desc.bInterfaceProtocol ==
> USB_INTERFACE_PROTOCOL_KEYBOARD) {
> usbhid_set_leds(hid);
> device_set_wakeup_enable(>dev, 1);
> }
>
> How about leaving everything the way it is now? If you want to enable
> wakeup for something like a USB mouse, you can write a udev script to do it
> as shown above.
>
> Alan Stern
Could we also enable wakeup for usb mouse? Or is there any concern to enable it?
Per my opinion, most people may expect clicking mouse can awake system.
Regards,
Du, Changbin
--
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] MADV_FREE doesn't work when doesn't have swap partition
> -Original Message- > From: Minchan Kim [mailto:minc...@kernel.org] > Sent: Friday, December 19, 2014 9:05 AM > To: Wang, Yalin > Cc: 'Konstantin Khlebnikov'; 'Kirill A. Shutemov'; 'Andrew Morton'; 'linux- > ker...@vger.kernel.org'; 'linux...@kvack.org'; 'linux-arm- > ker...@lists.infradead.org'; 'n-horigu...@ah.jp.nec.com' > Subject: Re: [RFC] MADV_FREE doesn't work when doesn't have swap partition > > On Thu, Dec 18, 2014 at 11:50:01AM +0800, Wang, Yalin wrote: > > I notice this commit: > > mm: support madvise(MADV_FREE), > > > > it can free clean anonymous pages directly, doesn't need pageout to > > swap partition, > > > > but I found it doesn't work on my platform, which don't enable any > > swap partitions. > > Current implementation, if there is no empty slot in swap, it does instant > free instead of delayed free. Look at madvise_vma. > > > > > I make a change for this. > > Just to explain my issue clearly, > > Do we need some other checks to still scan anonymous pages even Don't > > have swap partition but have clean anonymous pages? > > There is a few places we should consider if you want to scan anonymous page > withotu swap. Refer 69c854817566 and 74e3f3c3391d. > > However, it's not simple at the moment. If we reenable anonymous scan > without swap, it would make much regress of reclaim. So my direction is > move normal anonymos pages into unevictable LRU list because they're real > unevictable without swap and put delayed freeing pages into anon LRU list > and age them. > I understand your solution, sounds a great idea! When this design will be merged into main stream? Thanks.
Re: [PATCH] nfs: prevent truncate on active swapfile
On Thu, Dec 18, 2014 at 10:29:18PM -0800, Omar Sandoval wrote:
> Most filesystems prevent truncation of an active swapfile by way of
> inode_newsize_ok, called from inode_change_ok. NFS doesn't call either
> from nfs_setattr, presumably because most of these checks are expected
> to be done server-side. However, the IS_SWAPFILE check can only be done
> client-side, and not doing so is dangerous.
>
> Signed-off-by: Omar Sandoval
> ---
> fs/nfs/inode.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
> index 4bffe63..9205513 100644
> --- a/fs/nfs/inode.c
> +++ b/fs/nfs/inode.c
> @@ -506,10 +506,15 @@ nfs_setattr(struct dentry *dentry, struct iattr *attr)
> attr->ia_valid &= ~ATTR_MODE;
>
> if (attr->ia_valid & ATTR_SIZE) {
> + loff_t i_size;
> +
> BUG_ON(!S_ISREG(inode->i_mode));
>
> - if (attr->ia_size == i_size_read(inode))
> + i_size = i_size_read(inode);
> + if (attr->ia_size == i_size)
> attr->ia_valid &= ~ATTR_SIZE;
> + else if (attr->ia_size < i_size && IS_SWAPFILE(inode))
> + return -ETXTBSY;
> }
>
> /* Optimization: if the end result is no change, don't RPC */
> --
> 2.2.0
>
Sorry, forgot to mention that this applies to Linus' tree as of today.
--
Omar
--
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/
I'm a widow i need your assistance
-- 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: [PATCHv4 1/8] devfreq: event: Add new devfreq_event class to provide basic data for devfreq governor
Dear Myungjoo,
On 12/19/2014 11:11 AM, MyungJoo Ham wrote:
>>
>> Dear Myungjoo,
>>
>> Thanks for your review.
>>
>> On 12/18/2014 03:24 PM, MyungJoo Ham wrote:
>>> Hi Chanwoo,
>>>
>>> I love the idea and I now have a little mechanical issues in your code.
>>>
---
drivers/devfreq/Kconfig | 2 +
drivers/devfreq/Makefile| 5 +-
drivers/devfreq/devfreq-event.c | 449
drivers/devfreq/event/Makefile | 1 +
include/linux/devfreq.h | 160 ++
5 files changed, 616 insertions(+), 1 deletion(-)
create mode 100644 drivers/devfreq/devfreq-event.c
create mode 100644 drivers/devfreq/event/Makefile
>
> []
>
>>
>>>
>>>
>>> [snip]
>>>
diff --git a/drivers/devfreq/devfreq-event.c
b/drivers/devfreq/devfreq-event.c
new file mode 100644
index 000..0e1948e
--- /dev/null
+++ b/drivers/devfreq/devfreq-event.c
@@ -0,0 +1,449 @@
+/*
+ * devfreq-event: Generic DEVFREQ Event class driver
>>>
>>> DEVFREQ is a generic DVFS mechanism (or subsystem).
>>>
>>> Plus, I thought devfreq-event is considered to be a "framework"
>>> for devfreq event class drivers. Am I mistaken?
>>
>> You're right. just "class driver" description is not proper.
>> I'll modify the description of devfreq-event.c as following:
>> or If you have other opinion, would you please let me know about it?
>>
>> devfreq-event: DEVFREQ-Event Framework to provide raw data of Non-CPU
>> Devices.
>
> devfreq-event: a framework to provide raw data and events of devfreq devices
>
> should be enough.
OK, I'll modify it.
>
>
> []
>>> [snip / reversed maybe.. sorry]
>>>
+/**
+ * devfreq_event_is_enabled() - Check whether devfreq-event dev is
enabled or
+ * not.
+ * @edev : the devfreq-event device
+ *
+ * Note that this function check whether devfreq-event dev is enabled or
not.
+ * If return true, the devfreq-event dev is enabeld. If return false, the
+ * devfreq-event dev is disabled.
+ */
+bool devfreq_event_is_enabled(struct devfreq_event_dev *edev)
+{
+ bool enabled = false;
+
+ if (!edev || !edev->desc)
+ return enabled;
+
+ mutex_lock(>lock);
+
+ if (edev->enable_count > 0)
+ enabled = true;
+
+ if (edev->desc->ops && edev->desc->ops->is_enabled)
+ enabled |= edev->desc->ops->is_enabled(edev);
>>>
>>> What does it mean when enabled_count > 0 and ops->is_enabled() is false?
>>> or..
>>> What does it mean when enabled_count = 0 and ops->is_enabled() is true?
>>>
>>> If you do enable_count in the subsystem, why would we rely on
>>> ops->is_enabled()? Are you assuming that a device MAY turn itself off
>>> without any kernel control (ops->disable()) and it is still a correct
>>> behabior?
>>
>> You're right. devfreq_event_is_enabled() has ambiguous operation according
>> to your comment.
>>
>> I'll only control the enable_count in the subsystem without ops->is_enabled()
>> and then remove the is_enabled function in the structre devfreq_event_ops.
>>
>> Best Regards,
>> Chanwoo Choi
>>
>
> [Off-Topic]
>
> The name of devfreq-event may look quite intersecting with irq-driven
> governors,
> which are being proposed these days.
>
> Although they may look intersecting, we can have them independently;
> this as a sub-class and that as a governor. And we can consider to
> provide a common infrastructure for irq-driven mechanisms in devfreq or
> devfreq-event when we irq-driven DVFS become more general, which I
> expect in 2 ~ 3 years.
>
> So for now, both can go independently.
I understand your opinion.
I want to handle the devfreq-event framework independently from irq-driven
governor.
After completing the devfreq-event and the support for exynos-busfreq dt,
If you agree, I'll consider how to implement irq-driven governor as the devfreq
governor.
Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH net] r8152: drop the tx packet with invalid length
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Thursday, November 27, 2014 4:34 AM
[...]
> >> > Looks like a candidate for ndo_gso_check(), so that we do not drop, but
> >> > instead segment from netif_needs_gso()/validate_xmit_skb()
> >>
> >> You mean have the bridge implement the ndo_gso_check() method right?
> >
> > No, I meant this particular driver.
> >
> > Note that netif_skb_features() does only this check :
> >
> > if (gso_segs > dev->gso_max_segs || gso_segs < dev->gso_min_segs)
> > features &= ~NETIF_F_GSO_MASK;
> >
> > Ie not testing gso_max_size
> >
> > It looks like all these particular tests should be moved on
> > ndo_gso_check(), to remove code from netif_skb_features()
>
> A check against gso_max_size is generic enough that it ought to be put
> right into netif_needs_gso() rather then duplicating it into every
> driver's ndo_gso_check() method don't you think?
Excuse me. I try to implement ndo_gso_check() with kernel 3.18.
However, I still get packets with gso and their skb lengths are more
than the acceptable one. Do I miss something?
+static bool rtl8152_gso_check(struct sk_buff *skb, struct net_device *dev)
+{
+ if ((skb->len + sizeof(struct tx_desc)) > agg_buf_sz)
+ return false;
+
+ return true;
+}
@@ -5861,6 +5876,9 @@ static const struct net_device_ops rtl8152_netdev_ops = {
.ndo_set_mac_address= rtl8152_set_mac_address,
.ndo_change_mtu = rtl8152_change_mtu,
.ndo_validate_addr = eth_validate_addr,
+ .ndo_gso_check = rtl8152_gso_check,
};
Best Regards,
Hayes
--
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] nfs: prevent truncate on active swapfile
Most filesystems prevent truncation of an active swapfile by way of
inode_newsize_ok, called from inode_change_ok. NFS doesn't call either
from nfs_setattr, presumably because most of these checks are expected
to be done server-side. However, the IS_SWAPFILE check can only be done
client-side, and not doing so is dangerous.
Signed-off-by: Omar Sandoval
---
fs/nfs/inode.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
index 4bffe63..9205513 100644
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -506,10 +506,15 @@ nfs_setattr(struct dentry *dentry, struct iattr *attr)
attr->ia_valid &= ~ATTR_MODE;
if (attr->ia_valid & ATTR_SIZE) {
+ loff_t i_size;
+
BUG_ON(!S_ISREG(inode->i_mode));
- if (attr->ia_size == i_size_read(inode))
+ i_size = i_size_read(inode);
+ if (attr->ia_size == i_size)
attr->ia_valid &= ~ATTR_SIZE;
+ else if (attr->ia_size < i_size && IS_SWAPFILE(inode))
+ return -ETXTBSY;
}
/* Optimization: if the end result is no change, don't RPC */
--
2.2.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] swap: lock i_mutex for swap_writepage direct_IO
On Thu, Dec 18, 2014 at 10:24:05PM -0800, Omar Sandoval wrote: > + swap_file = file_open_name(name, O_RDWR | O_LARGEFILE | O_DIRECT, 0); > + if (IS_ERR(swap_file) && PTR_ERR(swap_file) == -EINVAL) ITYM if (swap_file == ERR_PTR(-EINVAL)) here... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] swap: lock i_mutex for swap_writepage direct_IO
On Wed, Dec 17, 2014 at 10:03:13PM +, Al Viro wrote:
> On Wed, Dec 17, 2014 at 10:52:56AM -0800, Christoph Hellwig wrote:
> > On Wed, Dec 17, 2014 at 06:58:32AM -0800, Omar Sandoval wrote:
> > > See my previous message. If we use O_DIRECT on the original open, then
> > > filesystems that implement bmap but not direct_IO will no longer work.
> > > These are the ones that I found in my tree:
> >
> > In the long run I don't think they are worth keeping. But to keep you
> > out of that discussion you can just try an open without O_DIRECT if the
> > open with the flag failed.
>
> Umm... That's one possibility, of course (and if swapon(2) is on someone's
> hotpath, I really would like to see what the hell they are doing - it has
> to be interesting in a sick way).
If this is the approach you'd prefer, I'll go ahead and do that for v2.
I personally think it looks pretty kludgey, but I'm fine either way:
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 63f55cc..c1b3073 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -2379,7 +2379,16 @@ SYSCALL_DEFINE2(swapon, const char __user *,
specialfile, int, swap_flags)
name = NULL;
goto bad_swap;
}
- swap_file = file_open_name(name, O_RDWR|O_LARGEFILE, 0);
+ swap_file = file_open_name(name, O_RDWR | O_LARGEFILE | O_DIRECT, 0);
+ if (IS_ERR(swap_file) && PTR_ERR(swap_file) == -EINVAL)
+ swap_file = file_open_name(name, O_RDWR | O_LARGEFILE, 0);
if (IS_ERR(swap_file)) {
error = PTR_ERR(swap_file);
swap_file = NULL;
> BTW, speaking of read/write vs. swap - what's the story with e.g. AFS
> write() checking IS_SWAPFILE() and failing with -EBUSY? Note that
> * it's done before acquiring i_mutex, so it isn't race-free
> * it's dubious from the POSIX POV - EBUSY isn't in the error
> list for write(2).
> * other filesystems generally don't have anything of that sort.
> NFS does, but local ones do not...
> Besides, do we even allow swapfiles on AFS?
AFS doesn't implement ->bmap or ->swap_activate, so that code is dead,
probably cargo-culted from the NFS code. It seems pretty pointless, not
only because it's inconsistent with the local filesystems like you
mentioned, but also because it's trivial to bypass with O_DIRECT on NFS:
ssize_t nfs_file_write(struct kiocb *iocb, struct iov_iter *from)
{
struct file *file = iocb->ki_filp;
struct inode *inode = file_inode(file);
unsigned long written = 0;
ssize_t result;
size_t count = iov_iter_count(from);
loff_t pos = iocb->ki_pos;
result = nfs_key_timeout_notify(file, inode);
if (result)
return result;
if (file->f_flags & O_DIRECT)
return nfs_file_direct_write(iocb, from, pos);
dprintk("NFS: write(%pD2, %zu@%Ld)\n",
file, count, (long long) pos);
result = -EBUSY;
if (IS_SWAPFILE(inode))
goto out_swapfile;
I think it's safe to scrap that code. However, this also led me to find that
NFS doesn't prevent truncates on an active swapfile. I'm submitting a patch for
that now.
--
Omar
--
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: [kpatch] [PATCH] livepatch v7: move x86 specific ftrace handler code to arch/x86
Sorry! Bad format, please ignore this patch. On 2014/12/19 13:37, Li Bin wrote: > The execution flow redirection related implemention in the livepatch > ftrace handler is depended on the specific architecture. This patch > introduces klp_arch_set_pc(like kgdb_arch_set_pc) interface to change > the pt_regs. > > Signed-off-by: Li Bin -- 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/
[kpatch] [PATCH] livepatch v7: move x86 specific ftrace handler code to arch/x86
The execution flow redirection related implemention in the livepatch
ftrace handler is depended on the specific architecture. This patch
introduces klp_arch_set_pc(like kgdb_arch_set_pc) interface to change
the pt_regs.
Signed-off-by: Li Bin
---
arch/x86/include/asm/livepatch.h |5 +
kernel/livepatch/core.c |2 +-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/livepatch.h b/arch/x86/include/asm/livepatch.h
index c2ae592..4cdec4e 100644
--- a/arch/x86/include/asm/livepatch.h
+++ b/arch/x86/include/asm/livepatch.h
@@ -21,6 +21,7 @@
#define _ASM_X86_LIVEPATCH_H
#include
+#include
#ifdef CONFIG_LIVE_PATCHING
#ifndef CC_USING_FENTRY
@@ -29,6 +30,10 @@
extern int klp_write_module_reloc(struct module *mod, unsigned long type,
unsigned long loc, unsigned long value);
+static inline void klp_arch_set_pc(struct pt_regs *regs, unsigned long ip)
+{
+ regs->ip = ip;
+}
#else
#error Live patching support is disabled; check CONFIG_LIVE_PATCHING
#endif
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 0004a71..c4c04fd 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -271,7 +271,7 @@ static void notrace klp_ftrace_handler(unsigned long ip,
{
struct klp_func *func = ops->private;
- regs->ip = (unsigned long)func->new_func;
+ klp_arch_set_pc(regs, (unsigned long)func->new_func);
}
static int klp_disable_func(struct klp_func *func)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v4 1/2] gpio: add GPIO hogging mechanism
On Fri, Dec 19, 2014 at 2:08 AM, Benoit Parrot wrote:
> Alexandre Courbot wrote on Wed [2014-Dec-17 17:41:51
> +0900]:
>> Looks ok to me. I have a few nits below, but otherwise I am happy with
>> how it turned out:
>>
>> Reviewed-by: Alexandre Courbot
> I'll add this to the next version.
>
>>
>> Thanks for your patience with this!
>>
>> On Sat, Dec 13, 2014 at 7:07 AM, Benoit Parrot wrote:
>> > Based on Boris Brezillion's work this is a reworked patch
>> > of his initial GPIO hogging mechanism.
>> > This patch provides a way to initally configure specific GPIO
>>
>> s/initally/initially
>>
>> > when the gpio controller is probed.
>>
>> GPIO in capitals please.
>>
>> >
>> > The actual DT scanning to collect the GPIO specific data is performed
>> > as part of the gpiochip_add().
>>
>> d/the
>>
>> >
>> > The purpose of this is to allows specific GPIOs to be configured
>>
>> s/allows/allow
>>
>> > without any driver specific code.
>> > This particularly useful because board design are getting
>>
>> This is particularly
>>
>> > increasingly complex and given SoC pins can now have upward
>> > of
>>
>> s/upward of/up to?
>
> well i meant more than 10 I think in some cases we have 13.
>
>>
>> > 10 mux values a lot of connections are now dependent on
>>
>> seems like a comma is missing here.
>>
>> > external IO muxes to switch various modes and combination.
>>
>> not sure what a combination is in that context.
>>
>> >
>> > Specific drivers should not necessarily need to be aware of
>> > what accounts to a specific board implementation. This board level
>> > "description" should be best kept as part of the dts file.
>> >
>> > Signed-off-by: Benoit Parrot
>> > ---
>> > Changes since v3:
>> > * Relocated the non-DT "hog" function to gpiolib.c.
>> > * Rename some of the function to be clearer and remove _ prefixes.
>> > * Replace the gpiod_request/gpiod_put usage with
>> >gpiochip_request_own_desc/free_own_desc version instead.
>> > * Refactor some of the logic to better handle error condition/reporting
>> > * Renamed the "direction" DT properties to "state".
>> >
>> > drivers/gpio/gpiolib-of.c | 119 ++
>> > drivers/gpio/gpiolib.c| 128
>> > ++
>> > drivers/gpio/gpiolib.h| 3 ++
>> > 3 files changed, 230 insertions(+), 20 deletions(-)
>> >
>> > diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
>> > index 604dbe6..5422216 100644
>> > --- a/drivers/gpio/gpiolib-of.c
>> > +++ b/drivers/gpio/gpiolib-of.c
>> > @@ -22,6 +22,7 @@
>> > #include
>> > #include
>> > #include
>> > +#include
>> >
>> > #include "gpiolib.h"
>> >
>> > @@ -111,6 +112,122 @@ int of_get_named_gpio_flags(struct device_node *np,
>> > const char *list_name,
>> > EXPORT_SYMBOL(of_get_named_gpio_flags);
>> >
>> > /**
>> > + * of_get_gpio_hog() - Get a GPIO hog descriptor, names and flags for
>> > GPIO API
>> > + * @np:device node to get GPIO from
>> > + * @name: GPIO line name
>> > + * @flags: a flags pointer to fill in
>> > + *
>> > + * Returns GPIO descriptor to use with Linux GPIO API, or one of the errno
>> > + * value on the error condition.
>> > + */
>> > +
>> > +static struct gpio_desc *of_get_gpio_hog(struct device_node *np,
>> > + const char **name,
>> > + enum gpio_lookup_flags *lflags,
>> > + enum gpiod_flags *dflags)
>> > +{
>> > + struct device_node *chip_np;
>> > + enum of_gpio_flags xlate_flags;
>> > + struct gpio_desc *desc;
>> > + const char *dir_val;
>> > + struct gg_data gg_data = {
>> > + .flags = _flags,
>> > + .out_gpio = NULL,
>>
>> out_gpio will be set to NULL if you don't specify it, so you don't
>> need this last line.
>
> ok
>
>>
>> > + };
>> > + u32 tmp;
>> > + int i, ret;
>> > +
>> > + chip_np = np->parent;
>> > + if (!chip_np)
>> > + return ERR_PTR(-EINVAL);
>> > +
>> > + xlate_flags = 0;
>> > + *lflags = 0;
>> > + *dflags = 0;
>> > +
>> > + ret = of_property_read_u32(chip_np, "#gpio-cells", );
>> > + if (ret)
>> > + return ERR_PTR(ret);
>> > +
>> > + if (tmp > MAX_PHANDLE_ARGS)
>> > + return ERR_PTR(-EINVAL);
>> > +
>> > + gg_data.gpiospec.args_count = tmp;
>> > + gg_data.gpiospec.np = chip_np;
>> > + for (i = 0; i < tmp; i++) {
>> > + ret = of_property_read_u32_index(np, "gpios", i,
>> > + _data.gpiospec.args[i]);
>> > + if (ret)
>> > + return ERR_PTR(ret);
>> > + }
>> > +
>> > + gpiochip_find(_data, of_gpiochip_find_and_xlate);
>> > + if (!gg_data.out_gpio) {
>> > + if (np->parent == np)
>> > + return ERR_PTR(-ENXIO);
>> > + else
>>
Re: [iwlwifi] BUG: unable to handle kernel
: :88001204fe28 EFLAGS: 00010246 > > > [5.354451] RSP: :88001204fe28 EFLAGS: 00010246 > > > [5.354451] RAX: RBX: 88000c08fe00 RCX: > > > 81d35310 > > > [5.354451] RAX: RBX: 88000c08fe00 RCX: > > > 81d35310 > > > [5.354451] RDX: 88000c08fe68 RSI: 826d05be RDI: > > > 8804e5f0 > > > [5.354451] RDX: 88000c08fe68 RSI: 826d05be RDI: > > > 8804e5f0 > > > [5.354451] RBP: 88001204fe28 R08: 0001 R09: > > > 033a > > > [5.354451] RBP: 88001204fe28 R08: 0001 R09: > > > 033a > > > [5.354451] R10: R11: 82531cd1 R12: > > > 88000c19fa00 > > > [5.354451] R10: R11: 82531cd1 R12: > > > 88000c19fa00 > > > [5.354451] R13: R14: 837958b8 R15: > > > > > > [5.354451] R13: R14: 837958b8 R15: > > > > > > [5.354451] FS: () GS:82789000() > > > knlGS: > > > [5.354451] FS: () GS:82789000() > > > knlGS: > > > [5.354451] CS: 0010 DS: ES: CR0: 8005003b > > > [5.354451] CS: 0010 DS: ES: CR0: 8005003b > > > [5.354451] CR2: 8804e5f0 CR3: 02776000 CR4: > > > 06b0 > > > [5.354451] CR2: 8804e5f0 CR3: 02776000 CR4: > > > 06b0 > > > [5.354451] Stack: > > > [5.354451] Stack: > > > [5.354451] 88001204fe58 > > > [5.354451] 88001204fe58 81d35334 81d35334 > > > 88000c19fa00 88000c19fa00 > > > > > > [5.354451] 826d05be > > > [5.354451] 826d05be > > > 88001204fe88 88001204fe88 81d35648 81d35648 > > > > > > [5.354451] 88000e3bbcc0 > > > [5.354451] 88000e3bbcc0 82b3fe61 82b3fe61 > > > 82b98910 82b98910 > > > > > > [5.354451] Call Trace: > > > [5.354451] Call Trace: > > > [5.354451] [] led_trigger_register+0x63/0x129 > > > [5.354451] [] led_trigger_register+0x63/0x129 > > > [5.354451] [] led_trigger_register_simple+0x35/0x79 > > > [5.354451] [] led_trigger_register_simple+0x35/0x79 > > > [5.354451] [] ? gs_bind+0xea/0xea > > > [5.354451] [] ? gs_bind+0xea/0xea > > > [5.354451] [] ledtrig_usb_init+0x17/0x2e > > > [5.354451] [] ledtrig_usb_init+0x17/0x2e > > > [5.354451] [] do_one_initcall+0xe6/0x171 > > > [5.354451] [] do_one_initcall+0xe6/0x171 > > > [5.354451] [] kernel_init_freeable+0xf8/0x180 > > > [5.354451] [] kernel_init_freeable+0xf8/0x180 > > > [5.354451] [] ? rest_init+0xbd/0xbd > > > [5.354451] [] ? rest_init+0xbd/0xbd > > > [5.354451] [] kernel_init+0x9/0xd0 > > > [5.354451] [] kernel_init+0x9/0xd0 > > > [5.354451] [] ret_from_fork+0x7a/0xb0 > > > [5.354451] [] ret_from_fork+0x7a/0xb0 > > > [5.354451] [] ? rest_init+0xbd/0xbd > > > [5.354451] [] ? rest_init+0xbd/0xbd > > > [5.354451] Code: > > > [5.354451] Code: c0 c0 eb eb f5 f5 31 31 c9 c9 40 40 8a 8a 3c 3c 0e > > > 0e 4d 4d 8d 8d 0c 0c 08 08 40 40 84 84 ff ff 41 41 88 88 3c 3c 08 08 74 > > > 74 0d 0d 48 48 ff ff c1 c1 48 48 39 39 ca ca 75 75 e7 e7 41 41 c6 c6 41 > > > 41 01 01 00 00 5d 5d c3 c3 55 55 31 31 c0 c0 48 48 89 89 e5 e5 <8a> <8a> > > > 14 14 07 07 3a 3a 14 14 06 06 74 74 07 07 19 19 c0 c0 83 83 c8 c8 01 01 > > > eb eb 09 09 48 48 ff ff c0 c0 84 84 d2 d2 75 75 > > > > > > [5.354451] RIP > > > [5.354451] RIP [] strcmp+0x6/0x20 > > > [] strcmp+0x6/0x20 > > > [5.354451] RSP > > > [5.354451] RSP > > > [5.354451] CR2: 8804e5f0 > > > [5.354451] CR2: 8804e5f0 > > > [ 5.354451] ---[ end trace 8f9377b34c860a0c ]--- > > > [5.354451] ---[ end trace 8f9377b34c860a0c ]--- > > > > > > git bisect start baa21e834941ee5fbe4bd421c871
Re: [PATCH RFC v2 08/14] drm: imx: Add MIPI DSI host controller driver
On 12/18/2014 07:39 PM, Philipp Zabel wrote:
Am Donnerstag, den 18.12.2014, 15:11 +0800 schrieb Liu Ying:
This patch adds i.MX MIPI DSI host controller driver support.
Currently, the driver supports the burst with sync pulses mode only.
Signed-off-by: Liu Ying
---
v1->v2:
* Address almost all comments from Thierry Reding and Russell.
* Update the DT documentation to remove the display-timings node in the panel
node.
* Update the DT documentation to state that the nodes which represent the
possible
DRM CRTCs the controller may connect with should be placed in the node
"ports".
* Remove the flag 'enabled' from the struct imx_mipi_dsi.
* Move the format_to_bpp() function in v1 to the common DRM MIPI DSI driver.
* Improve the way we wait for check status for DPHY and command packet
transfer.
* Improve the DPMS support for the encoder.
* Split the functions of ->host_attach() and ->mode_valid() clearly as
suggested by
Thierry Reding.
* Improve the logics in imx_mipi_dsi_dcs_long_write().
* Enable/disable the pllref_clk and pllref_gate_clk at the component
binding/unbinding
stages to help remove the flag 'enabled'.
* Update the module license to be "GPL".
* Other minor changes, such as coding style issues and macro naming issues.
.../devicetree/bindings/drm/imx/mipi_dsi.txt | 78 ++
drivers/gpu/drm/imx/Kconfig|6 +
drivers/gpu/drm/imx/Makefile |1 +
drivers/gpu/drm/imx/imx-mipi-dsi.c | 1056
4 files changed, 1141 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/imx/mipi_dsi.txt
create mode 100644 drivers/gpu/drm/imx/imx-mipi-dsi.c
diff --git a/Documentation/devicetree/bindings/drm/imx/mipi_dsi.txt
b/Documentation/devicetree/bindings/drm/imx/mipi_dsi.txt
new file mode 100644
index 000..892ed62
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/imx/mipi_dsi.txt
@@ -0,0 +1,78 @@
+Device-Tree bindings for MIPI DSI host controller
+
+MIPI DSI host controller
+
+
+The MIPI DSI host controller is a Synopsys DesignWare IP.
+It is a digital core that implements all protocol functions defined
+in the MIPI DSI specification, providing an interface between the
+system and the MIPI DPHY, and allowing communication with a MIPI DSI
+compliant display.
+
+Required properties:
+ - #address-cells: Should be <1>.
+ - #size-cells: Should be <0>.
+ - compatible: Should be "fsl,imx6q-mipi-dsi" for i.MX6q/sdl SoCs.
If this is a Synopsys DesignWare IP core as the HDMI TX, I think the
compatible should reflect that. How about a second compatible
"snps,dw-mipi-dsi"?
Ok, I'll add this second compatible string.
+ - reg: Physical base address of the controller and length of memory
+ mapped region.
+ - interrupts: The controller's interrupt number to the CPU(s).
+ - gpr: Should be <>.
+ The phandle points to the iomuxc-gpr region containing the
+ multiplexer control register for the controller.
+ - clocks, clock-names: Phandles to the controller pllref, pllref_gate
+ and core_cfg clocks, as described in [1] and [2].
+
+Required sub-nodes:
+ - ports: This node may contain up to four port nodes with endpoint
+ definitions as defined in [3], corresponding to the four inputs to
+ the controller multiplexer.
+ - A node to represent a DSI peripheral as described in [4].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/clock/imx6q-clock.txt
+[3] Documentation/devicetree/bindings/media/video-interfaces.txt
+[4] Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
+
+example:
+ gpr: iomuxc-gpr@020e {
+ /* ... */
+ };
+
+ mipi_dsi: mipi@021e {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,imx6q-mipi-dsi";
+ reg = <0x021e 0x4000>;
+ interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
+ gpr = <>;
+ clocks = < IMX6QDL_CLK_VIDEO_27M>,
+< IMX6QDL_CLK_HSI_TX>,
+< IMX6QDL_CLK_HSI_TX>;
+ clock-names = "pllref", "pllref_gate", "core_cfg";
Not sure about this. Are those names from the Synopsys documentation?
No, I don't think it's from there.
According to Table 41-1 in the i.MX6Q Reference Manual, this module has
6 clock inputs:
- ac_clk_125m (from ahb_clk_root)
- pixel_clk (from axi_clk_root)
- cfg_clk and pll_refclk (from video_27m)
- ips_clk and ipg_clk_s (from ipg_clk_root)
The CCM chapter says that of these, "ac_clk_125m", "cfg_clk", ips_clk",
and "pll_refclk" are gated by a single bit called
"mipi_core_cfg_clk_enable", that is clk[CLK_HSI_TX].
If that is correct, I see no reason for the "pllref_gate" clock.
I suppose two clocks "pllref" and "cfg" should suffice.
Using the two clocks makes the code look like
[PATCH] ftrace: fix typo in comment
%s/ARCH_SUPPORT_FTARCE_OPS/ARCH_SUPPORTS_FTRACE_OPS/ Signed-off-by: Li Bin --- kernel/trace/ftrace.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 929a733..9473b24 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -5102,7 +5102,7 @@ out: * being NULL, or CONFIG_DYNAMIC_FTRACE_WITH_REGS. * Note, CONFIG_DYNAMIC_FTRACE_WITH_REGS expects a full regs to be saved. * An architecture can pass partial regs with ftrace_ops and still - * set the ARCH_SUPPORT_FTARCE_OPS. + * set the ARCH_SUPPORTS_FTRACE_OPS. */ #if ARCH_SUPPORTS_FTRACE_OPS static void ftrace_ops_list_func(unsigned long ip, unsigned long parent_ip, -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' is set
> -Original Message- > From: Zhang, Yang Z > Sent: Friday, December 19, 2014 1:26 PM > To: Wu, Feng; Paolo Bonzini; k...@vger.kernel.org > Cc: io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; > k...@vger.kernel.org > Subject: RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' is set > > Wu, Feng wrote on 2014-12-19: > > > > > > Zhang, Yang Z wrote on 2014-12-19: > >> Subject: RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' is > >> set > >> > >> Wu, Feng wrote on 2014-12-19: > >>> > >>> > >>> Zhang, Yang Z wrote on 2014-12-19: > Subject: RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' > is set > > Wu, Feng wrote on 2014-12-19: > > > > > > iommu-boun...@lists.linux-foundation.org wrote on > mailto:iommu-boun...@lists.linux-foundation.org] On Behalf Of: > >> Cc: io...@lists.linux-foundation.org; > >> linux-kernel@vger.kernel.org; k...@vger.kernel.org > >> Subject: RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' > >> is set > >> > >> Paolo Bonzini wrote on 2014-12-18: > >>> > >>> > >>> On 18/12/2014 04:14, Wu, Feng wrote: > > > linux-kernel-ow...@vger.kernel.org wrote on > >> mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Paolo: > > x...@kernel.org; Gleb Natapov; Paolo Bonzini; > > dw...@infradead.org; > > joro-zlv9swrftaidnm+yrof...@public.gmane.org; Alex > Williamson; > > joro-zLv9SwRftAIdnm+Jiang Liu Cc: > > io...@lists.linux-foundation.org; > > linux-kernel-u79uwxl29ty76z2rm5m...@public.gmane.org; KVM > list; > > Eric Auger Subject: Re: [v3 25/26] KVM: Suppress > > posted-interrupt when 'SN' is set > > > > > > > > On 12/12/2014 16:14, Feng Wu wrote: > >> Currently, we don't support urgent interrupt, all > >> interrupts are recognized as non-urgent interrupt, so we > >> cannot send posted-interrupt when 'SN' is set. > > > > Can this happen? If the vcpu is in guest mode, it cannot > > have been scheduled out, and that's the only case when SN is set. > > > > Paolo > > Currently, the only place where SN is set is vCPU is > preempted and > >> > >> If the vCPU is preempted, shouldn't the subsequent be ignored? > >> What happens if a PI is occurs when vCPU is preempted? > > > > If a vCPU is preempted, the 'SN' bit is set, the subsequent > > interrupts are suppressed for posting. > > I mean what happens if we don't set SN bit. From my point, if > preempter already disabled the interrupt, it is ok to leave SN > bit as zero. But if preempter enabled the interrupt, doesn't this > mean he allow interrupt to happen? BTW, since there already has > ON bit, so this means there only have one interrupt arrived at > most and it doesn't hurt performance. Do we really need to set SN bit? > >>> > >>> > >>> See this scenario: > >>> vCPU0 is running on pCPU0 > >>> --> vCPU0 is preempted by vCPU1 > >>> --> Then vCPU1 is running on pCPU0 and vCPU0 is waiting for > >>> --> schedule in runqueue > >>> > >>> If the we don't set SN for vCPU0, then all subsequent interrupts > >>> for > >>> vCPU0 is posted to vCPU1, this will consume hardware and software > >> > >> The PI vector for vCPU1 is notification vector, but the PI vector > >> for > >> vCPU0 should be wakeup vector. Why vCPU1 will consume this PI event? > > > > Wakeup vector is only used for blocking case, when vCPU is preempted > > and waiting in the runqueue, the NV is the notification vector. > > I see your point. But from performance point, if we can schedule the vCPU to > another PCPU to handle the interrupt, it would helpful. But I remember current > KVM will not schedule the vCPU in run queue (even though it got preempted) to > another pCPU to run(Am I right?). So it may hard to do it. > KVM is using the Linux scheduler, when the preempted vCPU (in runqueue) is scheduled again depends on the scheduling algorithm itself, I think it is a little hard for us to get involved. I think what you mentioned is a little like the urgent interrupt in VT-d PI Spec. For this kind of interrupts, if an interrupt is coming for an preempted vCPU (waiting in the run queue), we need to schedule the vCPU immediately. This is some real time things. And we don't support urgent interrupt so far. Thanks, Feng > > > > Thanks, > > Feng > > > >> > >>> efforts and in fact it is not needed at all. If SN is set for > >>> vCPU0, VT-d hardware will not issue Notification Event for vCPU0 > >>> when an interrupt is for it, but just setting the related PIR bit. > >>> > >>> Thanks, > >>> Feng > >>> > > > > > Thanks, > > Feng > > > >> > waiting for the next scheduling in the runqueue. But I am not > sure whether we need to set SN for other purpose in
[kpatch] [PATCH] livepatch v7: move x86 specific ftrace handler code to arch/x86
The execution flow redirection related implemention in the livepatch
ftrace handler is depended on the specific architecture. This patch
introduces klp_arch_set_pc(like kgdb_arch_set_pc) interface to change
the pt_regs.
Signed-off-by: Li Bin
---
arch/x86/include/asm/livepatch.h |5 +
kernel/livepatch/core.c |2 +-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/livepatch.h b/arch/x86/include/asm/livepatch.h
index c2ae592..4cdec4e 100644
--- a/arch/x86/include/asm/livepatch.h
+++ b/arch/x86/include/asm/livepatch.h
@@ -21,6 +21,7 @@
#define _ASM_X86_LIVEPATCH_H
#include
+#include
#ifdef CONFIG_LIVE_PATCHING
#ifndef CC_USING_FENTRY
@@ -29,6 +30,10 @@
extern int klp_write_module_reloc(struct module *mod, unsigned long type,
unsigned long loc, unsigned long value);
+static inline void klp_arch_set_pc(struct pt_regs *regs, unsigned long ip)
+{
+ regs->ip = ip;
+}
#else
#error Live patching support is disabled; check CONFIG_LIVE_PATCHING
#endif
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 0004a71..c4c04fd 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -271,7 +271,7 @@ static void notrace klp_ftrace_handler(unsigned long ip,
{
struct klp_func *func = ops->private;
- regs->ip = (unsigned long)func->new_func;
+ klp_arch_set_pc(regs, (unsigned long)func->new_func);
}
static int klp_disable_func(struct klp_func *func)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm64: psci: Support generic pm suspend withtout CPUIDLE subsystem's help.
Current psci's cpu_suspend callback can be used only when common cpu idle
configuration is enabled. However, it's also needed for system which only
uses generic pm suspend not cpu idle. This patch modifies psci driver to
support both of cases.
Signed-off-by: Jonghwa Lee
---
arch/arm64/kernel/psci.c | 41 +
1 file changed, 29 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
index f1dbca7..06d5527 100644
--- a/arch/arm64/kernel/psci.c
+++ b/arch/arm64/kernel/psci.c
@@ -35,6 +35,13 @@
#define PSCI_POWER_STATE_TYPE_STANDBY 0
#define PSCI_POWER_STATE_TYPE_POWER_DOWN 1
+enum psci_affinity_level {
+ PSCI_AFFINITY_LEVEL_0,
+ PSCI_AFFINITY_LEVEL_1,
+ PSCI_AFFINITY_LEVEL_2,
+ PSCI_AFFINITY_LEVEL_3,
+};
+
struct psci_power_state {
u16 id;
u8 type;
@@ -513,27 +520,37 @@ static int psci_suspend_finisher(unsigned long index)
{
struct psci_power_state *state = __this_cpu_read(psci_power_state);
+ /* Generic PM suspend without CPUIDLE functionality */
+ if (!state) {
+ struct psci_power_state s = {
+ .affinity_level = PSCI_AFFINITY_LEVEL_3,
+ .type = PSCI_POWER_STATE_TYPE_POWER_DOWN,
+ };
+ return psci_ops.cpu_suspend(s, virt_to_phys(cpu_resume));
+ }
+
return psci_ops.cpu_suspend(state[index - 1],
virt_to_phys(cpu_resume));
}
static int __maybe_unused cpu_psci_cpu_suspend(unsigned long index)
{
- int ret;
struct psci_power_state *state = __this_cpu_read(psci_power_state);
- /*
-* idle state index 0 corresponds to wfi, should never be called
-* from the cpu_suspend operations
-*/
- if (WARN_ON_ONCE(!index))
- return -EINVAL;
- if (state[index - 1].type == PSCI_POWER_STATE_TYPE_STANDBY)
- ret = psci_ops.cpu_suspend(state[index - 1], 0);
- else
- ret = __cpu_suspend(index, psci_suspend_finisher);
+ if (state) {
+ if (WARN_ON_ONCE(!index))
+ return -EINVAL;
+
+ /*
+* If idle state initialization is successfully done,
+* idle state index 0 corresponds to wfi, should never be
+* called from the cpu_suspend operations
+*/
+ if (state[index - 1].type == PSCI_POWER_STATE_TYPE_STANDBY)
+ return psci_ops.cpu_suspend(state[index - 1], 0);
+ }
- return ret;
+ return __cpu_suspend(index, psci_suspend_finisher);
}
const struct cpu_operations cpu_psci_ops = {
--
1.7.9.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: [LKP] [sb_edac] 50d1bb93672: EDAC sbridge: ECC is disabled. Aborting
On Thu, 2014-12-18 at 09:05 -0200, Mauro Carvalho Chehab wrote:
> Hi Huang,
>
> Em Thu, 18 Dec 2014 16:13:26 +0800
> Huang Ying escreveu:
>
> > FYI, we noticed the below changes on
> >
> > commit 50d1bb93672fa2f42cec6e06ce799fbe864f57e9 ("sb_edac: add support for
> > Haswell based systems")
> >
> > Something new in kernel log. This may be expected. Just FYI.
> >
> > [ 12.490615] EDAC sbridge: Seeking for: PCI ID 8086:2fa0
> > [ 12.491031] EDAC sbridge: Seeking for: PCI ID 8086:2fa0
> > [ 12.491454] EDAC sbridge: Seeking for: PCI ID 8086:2ffc
> > [ 12.491865] EDAC sbridge: Seeking for: PCI ID 8086:2ffc
> > [ 12.492284] EDAC sbridge: Seeking for: PCI ID 8086:2ffd
> > [ 12.492698] EDAC sbridge: Seeking for: PCI ID 8086:2ffd
> > [ 12.493110] EDAC sbridge: Seeking for: PCI ID 8086:2f60
> > [ 12.493528] EDAC sbridge: Seeking for: PCI ID 8086:2fa8
> > [ 12.493943] EDAC sbridge: Seeking for: PCI ID 8086:2fa8
> > [ 12.494359] EDAC sbridge: Seeking for: PCI ID 8086:2f71
> > [ 12.494789] EDAC sbridge: Seeking for: PCI ID 8086:2f71
> > [ 12.495206] EDAC sbridge: Seeking for: PCI ID 8086:2faa
> > [ 12.495622] EDAC sbridge: Seeking for: PCI ID 8086:2faa
> > [ 12.496040] EDAC sbridge: Seeking for: PCI ID 8086:2fab
> > [ 12.496462] EDAC sbridge: Seeking for: PCI ID 8086:2fab
> > [ 12.496878] EDAC sbridge: Seeking for: PCI ID 8086:2fac
> > [ 12.497297] EDAC sbridge: Seeking for: PCI ID 8086:2fac
> > [ 12.497714] EDAC sbridge: Seeking for: PCI ID 8086:2fad
> > [ 12.497923] IOAPIC[0]: Set routing entry (8-22 -> 0xb3 -> IRQ 22 Mode:1
> > Active:1 Dest:1)
> > [ 12.497927] IOAPIC[0]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1
> > Trig_Mode:0 Dlvry_Mode:1 Avail:0 Vector:B3 Dest:0001 SID:F0FF SQ:0
> > SVT:1)
> > [ 12.497981] snd_hda_intel :00:1b.0: irq 75 for MSI/MSI-X
> > [ 12.498086] IOAPIC[1]: Set routing entry (9-12 -> 0xe3 -> IRQ 36 Mode:1
> > Active:1 Dest:1)
> > [ 12.498089] IOAPIC[1]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1
> > Trig_Mode:0 Dlvry_Mode:1 Avail:0 Vector:E3 Dest:0001 SID:002C SQ:0
> > SVT:1)
> > [ 12.498093] snd_hda_intel :02:00.1: Disabling MSI
> > [ 12.498109] snd_hda_intel :02:00.1: Handle VGA-switcheroo audio
> > client
> > [ 12.502542] EDAC sbridge: Seeking for: PCI ID 8086:2fad
> > [ 12.502956] EDAC sbridge: Seeking for: PCI ID 8086:2fbd
> > [ 12.503365] EDAC sbridge: Seeking for: PCI ID 8086:2f68
> > [ 12.503781] EDAC sbridge: Seeking for: PCI ID 8086:2f68
> > [ 12.504197] EDAC sbridge: Seeking for: PCI ID 8086:2f79
> > [ 12.504620] EDAC sbridge: Seeking for: PCI ID 8086:2f6a
> > [ 12.505041] EDAC sbridge: Seeking for: PCI ID 8086:2f6b
> > [ 12.505452] EDAC sbridge: Seeking for: PCI ID 8086:2f6c
> > [ 12.505869] EDAC sbridge: Seeking for: PCI ID 8086:2f6d
> > [ 12.506298] EDAC sbridge: ECC is disabled. Aborting
> > [ 12.506718] EDAC sbridge: Couldn't find mci handler
>
> Not sure about what are you complaining, since you didn't show how was
> the log before.
In fact, I am not complaining :-), just FYI. As I said, this may be a
expected behavior because this is a Haswell machine and the Haswell
support was added in this patch.
> From the above, what looks weird, from EDAC driver PoV, is:
> [ 12.506298] EDAC sbridge: ECC is disabled. Aborting
This is what I want help from you to confirm whether it is abnormal.
> Does it used to work before? If so, was there any BIOS setting change?
> Does the memories used on this machine have ECC?
This is a high-end desktop, there is something as below in dmidecode
output. Is there some other way to tell whether the memories have ECC?
Handle 0x0018, DMI type 16, 23 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: Multi-bit ECC
Maximum Capacity: 128 GB
Error Information Handle: Not Provided
Number Of Devices: 4
Handle 0x001A, DMI type 17, 34 bytes
Memory Device
Array Handle: 0x0018
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 72 bits
Size: 8192 MB
Form Factor: DIMM
Set: None
Locator: DIMM_A1
Bank Locator: CPU 0
Type:
Type Detail: Synchronous
Speed: 1067 MHz
Manufacturer: 0x11
Serial Number: Unknown
Asset Tag: Unknown
Part Number: Unknown
Rank: 1
Configured Clock Speed: Unknown
Best Regards,
Huang, Ying
--
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: [LKP] [cpufreq] BUG: sleeping function called from invalid context at mm/slub.c:1241
On Fri, Dec 19, 2014 at 10:17 AM, Huang Ying wrote:
> FYI, we noticed the below changes on
>
> https://git.linaro.org/people/vireshk/linux cpufreq/stats/cleanups
> commit 2136fa84639adcc0727e968f99ad222c8146810c ("cpufreq: stats: Fix
> locking")
>
>
> +--+++
> | | 0063f8602b | 2136fa8463 |
> +--+++
> | boot_successes | 9 | 9 |
> | boot_failures| 1 | 1 |
> | BUG:kernel_boot_hang | 1 | 1 |
> +--+++
>
>
> [ 24.295182] Freeing unused kernel memory: 1972K (880001a13000 -
> 880001c0)
> [ 24.304471] Freeing unused kernel memory: 1780K (880002043000 -
> 88000220)
> [ 24.704332] acpi-cpufreq: overriding BIOS provided _PSD data
> [ 24.716589] BUG: sleeping function called from invalid context at
> mm/slub.c:1241
> [ 24.726087] in_atomic(): 1, irqs_disabled(): 0, pid: 2393, name: modprobe
> [ 24.726092] CPU: 21 PID: 2393 Comm: modprobe Not tainted 3.18.0-g0a0a28c #1
> [ 24.726093] Hardware name: Supermicro H8DGU/H8DGU, BIOS 2.009/08/11
> [ 24.726097] 04d9 8810071a3ae8 81a02d59
> 0f340f34
> [ 24.726099] 81effec4 8810071a3af8 8110adca
> 8810071a3b28
> [ 24.726101] 8110ae7d 80d0
> 88040f803b00
> [ 24.726102] Call Trace:
> [ 24.726111] [] dump_stack+0x4c/0x65
> [ 24.726117] [] ___might_sleep+0x10e/0x110
> [ 24.726119] [] __might_sleep+0xb1/0xb9
> [ 24.726123] [] kmem_cache_alloc_trace+0x48/0x1e6
> [ 24.726128] [] ? __cpufreq_stats_create_table+0x68/0x194
> [ 24.726131] [] __cpufreq_stats_create_table+0x68/0x194
> [ 24.726138] [] cpufreq_stat_notifier_policy+0x1b/0x32
> [ 24.726141] [] notifier_call_chain+0x6d/0x95
> [ 24.726143] [] __blocking_notifier_call_chain+0x4a/0x63
> [ 24.726145] [] blocking_notifier_call_chain+0x14/0x16
> [ 24.726148] [] __cpufreq_add_dev+0x71d/0x8ce
> [ 24.726150] [] cpufreq_add_dev+0xe/0x10
> [ 24.726154] [] subsys_interface_register+0xb8/0xdf
> [ 24.726157] [] cpufreq_register_driver+0x156/0x268
> [ 24.726159] [] ? 0xa009f000
> [ 24.726163] [] acpi_cpufreq_init+0x220/0x1000
> [acpi_cpufreq]
> [ 24.726165] [] ? 0xa009f000
> [ 24.726168] [] do_one_initcall+0xfd/0x18f
> [ 24.726172] [] ? __vunmap+0xac/0xb7
> [ 24.726176] [] load_module+0x1a35/0x1ff7
> [ 24.726179] [] ? kernel_read+0x48/0x5f
> [ 24.726183] [] SyS_finit_module+0x85/0x92
> [ 24.726187] [] system_call_fastpath+0x12/0x17
> [ 25.539283] microcode: CPU0: patch_level=0x06000613
> [ 25.544884] microcode: CPU1: patch_level=0x06000613
> [ 25.550137] microcode: CPU2: patch_level=0x06000613
Okay, thanks Huang..
The problem is that we are trying to allocate memory from within spinlock's
critical region..
Fixed by replacing spinlock with a mutex. Pushed my branch again.
--
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: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' is set
Wu, Feng wrote on 2014-12-19: > > > Zhang, Yang Z wrote on 2014-12-19: >> Subject: RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' is >> set >> >> Wu, Feng wrote on 2014-12-19: >>> >>> >>> Zhang, Yang Z wrote on 2014-12-19: Subject: RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' is set Wu, Feng wrote on 2014-12-19: > > > iommu-boun...@lists.linux-foundation.org wrote on mailto:iommu-boun...@lists.linux-foundation.org] On Behalf Of: >> Cc: io...@lists.linux-foundation.org; >> linux-kernel@vger.kernel.org; k...@vger.kernel.org >> Subject: RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' >> is set >> >> Paolo Bonzini wrote on 2014-12-18: >>> >>> >>> On 18/12/2014 04:14, Wu, Feng wrote: linux-kernel-ow...@vger.kernel.org wrote on >> mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Paolo: > x...@kernel.org; Gleb Natapov; Paolo Bonzini; > dw...@infradead.org; > joro-zlv9swrftaidnm+yrof...@public.gmane.org; Alex Williamson; > joro-zLv9SwRftAIdnm+Jiang Liu Cc: > io...@lists.linux-foundation.org; > linux-kernel-u79uwxl29ty76z2rm5m...@public.gmane.org; KVM list; > Eric Auger Subject: Re: [v3 25/26] KVM: Suppress > posted-interrupt when 'SN' is set > > > > On 12/12/2014 16:14, Feng Wu wrote: >> Currently, we don't support urgent interrupt, all >> interrupts are recognized as non-urgent interrupt, so we >> cannot send posted-interrupt when 'SN' is set. > > Can this happen? If the vcpu is in guest mode, it cannot > have been scheduled out, and that's the only case when SN is set. > > Paolo Currently, the only place where SN is set is vCPU is preempted and >> >> If the vCPU is preempted, shouldn't the subsequent be ignored? >> What happens if a PI is occurs when vCPU is preempted? > > If a vCPU is preempted, the 'SN' bit is set, the subsequent > interrupts are suppressed for posting. I mean what happens if we don't set SN bit. From my point, if preempter already disabled the interrupt, it is ok to leave SN bit as zero. But if preempter enabled the interrupt, doesn't this mean he allow interrupt to happen? BTW, since there already has ON bit, so this means there only have one interrupt arrived at most and it doesn't hurt performance. Do we really need to set SN bit? >>> >>> >>> See this scenario: >>> vCPU0 is running on pCPU0 >>> --> vCPU0 is preempted by vCPU1 >>> --> Then vCPU1 is running on pCPU0 and vCPU0 is waiting for >>> --> schedule in runqueue >>> >>> If the we don't set SN for vCPU0, then all subsequent interrupts >>> for >>> vCPU0 is posted to vCPU1, this will consume hardware and software >> >> The PI vector for vCPU1 is notification vector, but the PI vector >> for >> vCPU0 should be wakeup vector. Why vCPU1 will consume this PI event? > > Wakeup vector is only used for blocking case, when vCPU is preempted > and waiting in the runqueue, the NV is the notification vector. I see your point. But from performance point, if we can schedule the vCPU to another PCPU to handle the interrupt, it would helpful. But I remember current KVM will not schedule the vCPU in run queue (even though it got preempted) to another pCPU to run(Am I right?). So it may hard to do it. > > Thanks, > Feng > >> >>> efforts and in fact it is not needed at all. If SN is set for >>> vCPU0, VT-d hardware will not issue Notification Event for vCPU0 >>> when an interrupt is for it, but just setting the related PIR bit. >>> >>> Thanks, >>> Feng >>> > > Thanks, > Feng > >> waiting for the next scheduling in the runqueue. But I am not sure whether we need to set SN for other purpose in future. Adding SN checking here is just to follow the Spec. non-urgent interrupts are suppressed >>> when SN is set. >>> >>> I would change that to a WARN_ON_ONCE then. >> >> >> Best regards, >> Yang >> >> >> ___ >> iommu mailing list >> io...@lists.linux-foundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/iommu Best regards, Yang >> >> >> Best regards, >> Yang >> Best regards, Yang -- 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: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc
Hi Roger,
On Thursday 18 December 2014 09:22 PM, Roger Quadros wrote:
> Fixing up Paul's email id.
>
> cheers,
> -roger
>
> On 18/12/14 17:49, Roger Quadros wrote:
>> There are quite a few hwmods that don't have sysconfig register and so
>> _find_mpu_rt_port(oh) will return NULL thus preventing ready state check
>> on those modules after the module is enabled.
>>
>> This can potentially cause a bus access error if the module is accessed
>> before the module is ready.
>>
>> Get rid of the redundant _find_mpu_rt_port() check from the
>> _wait_target_ready()
>> funcion for all the SoCs. The following PRCM register access that checks the
>> module ready state has nothing to do with module's SYSCONFIG or mpu_rt_port.
Yes, makes sense. This patch looks good to me.
Tested this on AM437x-gp-evm.
Tested-by: Lokesh Vutla
May be good idea to warn every time if enabling of module is failed?
Unrelated to this patch though.
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 4c6b7b2..db67b66 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2243,7 +2243,7 @@ static int _enable(struct omap_hwmod *oh)
if (soc_ops.disable_module)
soc_ops.disable_module(oh);
_disable_clocks(oh);
- pr_debug("omap_hwmod: %s: _wait_target_ready: %d\n",
+ pr_warn("omap_hwmod: %s: _wait_target_ready failed : %d\n",
oh->name, r);
if (oh->clkdm)
Thanks and regards,
Lokesh
>>
>> e.g. this fixes the below DCAN bus access error on AM437x-gp-evm.
>>
>> [ 16.672978] [ cut here ]
>> [ 16.677885] WARNING: CPU: 0 PID: 1580 at drivers/bus/omap_l3_noc.c:147
>> l3_interrupt_handler+0x234/0x35c()
>> [ 16.687946] 4400.ocp:L3 Custom Error: MASTER M2 (64-bit) TARGET
>> L4_PER_0 (Read): Data Access in User mode during Functional access
>> [ 16.700654] Modules linked in: xhci_hcd btwilink ti_vpfe dwc3
>> videobuf2_core ov2659 bluetooth v4l2_common videodev ti_am335x_adc kfifo_buf
>> industrialio c_can_platform videobuf2_dma_contig media snd_soc_tlv320aic3x
>> pixcir_i2c_ts c_can dc
>> [ 16.731144] CPU: 0 PID: 1580 Comm: rpc.statd Not tainted
>> 3.14.26-02561-gf733aa036398 #180
>> [ 16.739747] Backtrace:
>> [ 16.742336] [] (dump_backtrace) from []
>> (show_stack+0x18/0x1c)
>> [ 16.750285] r6:0093 r5:0009 r4:eab5b8a8 r3:
>> [ 16.756252] [] (show_stack) from []
>> (dump_stack+0x20/0x28)
>> [ 16.763870] [] (dump_stack) from []
>> (warn_slowpath_common+0x6c/0x8c)
>> [ 16.772408] [] (warn_slowpath_common) from []
>> (warn_slowpath_fmt+0x38/0x40)
>> [ 16.781550] r8:c05d1f90 r7:c0730844 r6:c0730448 r5:80080003 r4:ed0cd210
>> [ 16.788626] [] (warn_slowpath_fmt) from []
>> (l3_interrupt_handler+0x234/0x35c)
>> [ 16.797968] r3:ed0cd480 r2:c0730508
>> [ 16.801747] [] (l3_interrupt_handler) from []
>> (handle_irq_event_percpu+0x54/0x1bc)
>> [ 16.811533] r10:ed005600 r9:c084855b r8:002a r7: r6:
>> r5:002a
>> [ 16.819780] r4:ed0e6d80
>> [ 16.822453] [] (handle_irq_event_percpu) from []
>> (handle_irq_event+0x30/0x40)
>> [ 16.831789] r10:eb2b6938 r9:eb2b6960 r8:bf011420 r7:fa240100 r6:
>> r5:002a
>> [ 16.840052] r4:ed005600
>> [ 16.842744] [] (handle_irq_event) from []
>> (handle_fasteoi_irq+0x74/0x128)
>> [ 16.851702] r4:ed005600 r3:
>> [ 16.855479] [] (handle_fasteoi_irq) from []
>> (generic_handle_irq+0x28/0x38)
>> [ 16.864523] r4:002a r3:c0066164
>> [ 16.868294] [] (generic_handle_irq) from []
>> (handle_IRQ+0x38/0x8c)
>> [ 16.876612] r4:c081c640 r3:0202
>> [ 16.880380] [] (handle_IRQ) from []
>> (gic_handle_irq+0x30/0x5c)
>> [ 16.888328] r6:eab5ba38 r5:c0804460 r4:fa24010c r3:0100
>> [ 16.894303] [] (gic_handle_irq) from []
>> (__irq_svc+0x40/0x50)
>> [ 16.902193] Exception stack(0xeab5ba38 to 0xeab5ba80)
>> [ 16.907499] ba20:
>> 0006
>> [ 16.916108] ba40: fa1d fa1d0008 ed3d3000 eab5bab4 ed3d3460 c0842af4
>> bf011420 eb2b6960
>> [ 16.924716] ba60: eb2b6938 eab5ba8c eab5ba90 eab5ba80 bf035220 bf07702c
>> 600f0013
>> [ 16.933317] r7:eab5ba6c r6: r5:600f0013 r4:bf07702c
>> [ 16.939317] [] (c_can_plat_read_reg_aligned_to_16bit
>> [c_can_platform]) from [] (c_can_get_berr_counter+0x38/0x64
>> [c_can])
>> [ 16.952696] [] (c_can_get_berr_counter [c_can]) from
>> [] (can_fill_info+0x124/0x15c [can_dev])
>> [ 16.963480] r5:ec8c9740 r4:ed3d3000
>> [ 16.967253] [] (can_fill_info [can_dev]) from []
>> (rtnl_fill_ifinfo+0x58c/0x8fc)
>> [ 16.976749] r6:ec8c9740 r5:ed3d3000 r4:eb2b6780
>> [ 16.981613] [] (rtnl_fill_ifinfo) from []
>> (rtnl_dump_ifinfo+0xf0/0x1dc)
>> [ 16.990401] r10:ec8c9740 r9: r8: r7: r6:ebd4d1b4
>> r5:ed3d3000
>> [ 16.998671]
Re: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration
On 19 December 2014 at 05:18, Roopa Prabhu wrote:
> On 12/18/14, 3:26 PM, Samudrala, Sridhar wrote:
>>
>>
>> On 12/18/2014 3:07 PM, Roopa Prabhu wrote:
>>>
>>> On 12/18/14, 11:21 AM, John Fastabend wrote:
On 12/18/2014 10:14 AM, Roopa Prabhu wrote:
>
> On 12/18/14, 10:02 AM, Varlese, Marco wrote:
>>
>> Removed unnecessary content for ease of reading...
>>
+/* Switch Port Attributes section */
+
+enum {
+IFLA_ATTR_UNSPEC,
+IFLA_ATTR_LEARNING,
>>>
>>> Any reason you want learning here ?. This is covered as part of
>>> the bridge setlink attributes.
>>>
>> Yes, because the user may _not_ want to go through a bridge
>> interface
>
> necessarily.
> But, the bridge setlink/getlink interface was changed to
> accommodate
>>>
>>> 'self'
>
> for exactly such cases.
> I kind of understand your case for the other attributes (these are
> per port settings that switch asics provide).
>
> However, i don't understand the reason to pull in bridge attributes
> here.
>
Maybe, I am missing something so you might help. The learning
attribute -
>>>
>>> in my case - it is like all other attributes: a port attribute (as
>>> you said, port
>>> settings that the switch provides per port).
So, what I was saying is "why the user shall go through a bridge to
configure
>>>
>>> the learning attribute"? From my perspective, it is as any other
>>> attribute and
>>> as such configurable on the port.
>>>
>>> Thinking about this some more, i don't see why any of these
>>> attributes
>>> (except loopback. I dont understand the loopback attribute) cant be
>>> part of
>>> the birdge port attributes.
>>>
>>> With this we will end up adding l2 attributes in two places: the
>>> general link
>>> attributes and bridge attributes.
>>>
>>> And since we have gone down the path of using
>>> ndo_bridge_setlink/getlink
>>> with 'self'we should stick to that for all l2 attributes.
>>>
>>> The idea of overloading ndo_bridge_set/getlink, was to have the same
>>> set of
>>> attributes but support both cases where the user wants to go through
>>> the
>>> bridge driver or directly to the switch port driver. So, you are not
>>> really going
>>> through the bridge driver if you use 'self' and
>>> ndo_bridge_setlink/getlink.
>>>
>> Roopa, one of the comments I got from Thomas Graf on my v1 patch
>> was that your patch and mine were supplementary ("I think Roopa's
>> patches are supplementary. Not all switchdev users will be backed
>> with a Linux Bridge. I therefore welcome your patches very
>> much")... I also understood by others that the patch made sense for
>> the same reason. I simply do not understand why these attributes
>> (and maybe others in the future) could not be configured directly
>> on a standard port but have to go through a bridge.
>>
> ok, i am very confused in that case. The whole moving of bridge
> attributes from the bridge driver to rtnetlink.c was to make the
> bridge attributes accessible to any driver who wants to set l2/bridge
> attributes on their switch ports. So, its unclear to me why we are
> doing this parallel thing again. This move to rtnetlink.c was done
> during the recent rocker support. so, maybe scott/jiri can elaborate
> more.
Not sure if this will add to the confusion or help. But you do not
need to have the bridge.ko loaded or netdev's attached to a bridge
to use the setlink/getlink ndo ops and netlink messages.
This was intentionally done. Its already used with NIC devices to
configure embedded bridge settings such as VEB/VEPA.
>>>
>>>
>>> that helps my case, thanks.
>>
>>
>> So the user interface to set/get the per-port attributes will be via
>> 'bridge', not 'ip'
>>
>> bridge link set dev sw0p1 port_attr bcast_flooding 1 self
>> bridge link get dev sw0p1 port_attr bcast_flooding self
>
>
> yes, l2 attributes.
>>
>>
>> We also need an interface to set per-switch attributes. Can this work?
>> bridge link set dev sw0 sw_attr bcast_flooding 1 master
>> where sw0 is a bridge representing the hardware switch.
>
>
> Not today. We discussed this @ LPC, and one way to do this would be to have
> a device
> representing the switch asic. This is in the works.
Can I assume that on platforms which house more than one asic (say
two 24 port asics, interconnected via a 10G link or equivalent, to get
a 48 port 'switch') , the 'rocker' driver (or similar) should expose
them as a single set of ports, and not as two 'switch ports' ?
>
>
> --
> To unsubscribe from this list: send the line
Re: [PULL] modules-next
On Thu, Dec 18, 2014 at 4:55 PM, Rusty Russell wrote: > > The exciting thing here is the getting rid of stop_machine on module > removal. This is possible by using a simple atomic_t for the counter, > rather than our fancy per-cpu counter: it turns out that no one is doing > a module increment per net packet, so the slowdown should be in the noise. Famous last words. It may not happen per-packet, but I see module_get() in various block drivers and in netfilter code etc, and some of them may be pretty bad. Let's see how it all works out. 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/
[LKP] [vmstat] 7cc36bbddde: +2.6% will-it-scale.scalability -28.7% time.involuntary_context_switches
FYI, we noticed the below changes on
commit 7cc36bbddde5cd0c98f0c06e3304ab833d662565 ("vmstat: on-demand vmstat
workers V8")
testbox/testcase/testparams: lkp-sbx04/will-it-scale/performance-pread2
f0d6d1f6ff6f8525 7cc36bbddde5cd0c98f0c06e33
--
%stddev %change %stddev
\ |\
0.00 ± 1% +2.6% 0.00 ± 1% will-it-scale.scalability
533566 ± 0% -1.2% 527362 ± 0% will-it-scale.per_process_ops
486263 ± 0% -0.9% 481764 ± 0% will-it-scale.per_thread_ops
355 ± 14%+163.0%933 ± 37% sched_debug.cpu#20.curr->pid
6 ± 34%+148.0% 15 ± 11% sched_debug.cfs_rq[52]:/.load
11214 ± 48% -55.6% 4973 ± 14%
sched_debug.cfs_rq[11]:/.exec_clock
5 ± 31% -55.0% 2 ± 48% sched_debug.cpu#5.cpu_load[1]
88729 ± 46% -53.2% 41487 ± 3%
sched_debug.cfs_rq[11]:/.min_vruntime
408 ± 34% -56.8%176 ± 3% sched_debug.cpu#43.ttwu_local
7 ± 34%+114.3% 15 ± 12% sched_debug.cpu#52.load
13 ± 46% +70.4% 23 ± 26% sched_debug.cpu#43.load
4 ± 17%+105.3% 9 ± 19%
sched_debug.cfs_rq[6]:/.blocked_load_avg
6562 ± 25%+120.1% 14443 ± 16% sched_debug.cfs_rq[7]:/.exec_clock
3 ± 22% -46.7% 2 ± 0%
sched_debug.cfs_rq[28]:/.blocked_load_avg
68456 ± 17% -39.7% 41302 ± 47% sched_debug.cfs_rq[46]:/.spread0
187 ± 15% -38.2%115 ± 18% sched_debug.cpu#40.ttwu_local
941 ± 25% +76.9% 1665 ± 19% sched_debug.cpu#52.curr->pid
11 ± 3%+104.4% 23 ± 49%
sched_debug.cfs_rq[48]:/.tg_load_contrib
534 ± 20% +87.9% 1003 ± 48% sched_debug.cpu#6.ttwu_local
51437 ± 28% +55.8% 80132 ± 19%
sched_debug.cfs_rq[8]:/.min_vruntime
14311 ± 23% +67.2% 23936 ± 24% sched_debug.cpu#22.sched_goidle
9 ± 8% -35.9% 6 ± 26% sched_debug.cpu#39.cpu_load[4]
14113 ± 24% +66.8% 23537 ± 25% sched_debug.cpu#22.ttwu_count
28742 ± 23% +66.8% 47938 ± 24% sched_debug.cpu#22.nr_switches
7 ± 17% -27.6% 5 ± 20% sched_debug.cpu#42.cpu_load[0]
58556 ± 16% -32.5% 39547 ± 4%
sched_debug.cfs_rq[12]:/.min_vruntime
199 ± 9% -37.1%125 ± 12% sched_debug.cpu#46.ttwu_local
161308 ± 28% -45.6% 87699 ± 30% sched_debug.cpu#2.sched_goidle
322838 ± 28% -45.6% 175601 ± 30% sched_debug.cpu#2.nr_switches
188 ± 8% -30.3%131 ± 11% sched_debug.cpu#47.ttwu_local
330608 ± 31% -46.5% 176795 ± 29% sched_debug.cpu#2.sched_count
407 ± 12% +39.7%568 ± 10% sched_debug.cpu#30.ttwu_local
75 ± 21% +31.5% 99 ± 19%
sched_debug.cfs_rq[8]:/.tg_runnable_contrib
9 ± 15% -33.3% 6 ± 11% sched_debug.cpu#36.cpu_load[1]
3494 ± 21% +31.0% 4578 ± 18%
sched_debug.cfs_rq[8]:/.avg->runnable_avg_sum
304 ± 9% -28.7%217 ± 9% sched_debug.cpu#39.ttwu_local
118 ± 10% -25.2% 88 ± 11% sched_debug.cpu#48.ttwu_local
171927 ± 32% -45.5% 93673 ± 34% sched_debug.cpu#2.ttwu_count
68928 ± 14% -41.9% 40061 ± 46% sched_debug.cfs_rq[40]:/.spread0
9 ± 11% -33.3% 6 ± 17% sched_debug.cpu#38.cpu_load[4]
9 ± 15% -25.6% 7 ± 15% sched_debug.cpu#38.cpu_load[3]
537 ± 15% -28.3%385 ± 14% sched_debug.cpu#9.ttwu_local
2694 ± 15% -21.5% 2116 ± 6%
sched_debug.cfs_rq[16]:/.avg->runnable_avg_sum
58 ± 15% -21.1% 45 ± 6%
sched_debug.cfs_rq[16]:/.tg_runnable_contrib
0.05 ± 8% +33.3% 0.07 ± 10% turbostat.%c3
130948 ± 11% -40.3% 78138 ± 47% sched_debug.cfs_rq[39]:/.spread0
282 ± 10% -22.1%220 ± 7% sched_debug.cpu#38.ttwu_local
20679 ± 18% -26.9% 15120 ± 17% numa-meminfo.node2.Active(anon)
5170 ± 18% -26.9% 3778 ± 17% numa-vmstat.node2.nr_active_anon
36499 ± 4% -24.1% 27721 ± 8%
sched_debug.cfs_rq[39]:/.exec_clock
259406 ± 8% -19.7% 208230 ± 10%
sched_debug.cfs_rq[39]:/.min_vruntime
125 ± 5% -20.5% 99 ± 14% sched_debug.cpu#55.ttwu_local
23 ± 10% -26.1% 17 ± 19% sched_debug.cfs_rq[44]:/.load
82250 ± 9% -20.9% 65029 ± 11%
sched_debug.cfs_rq[2]:/.min_vruntime
80988 ± 8% +17.1% 94812 ± 7% meminfo.DirectMap4k
47 ± 10% +15.3% 54 ± 8%
sched_debug.cfs_rq[20]:/.tg_runnable_contrib
73 ± 7% -22.9% 56 ± 8% sched_debug.cpu#63.ttwu_local
46694 ± 4% +29.7% 60558 ± 7% sched_debug.cpu#7.nr_load_updates
2205 ± 9% +15.1% 2539 ± 8%
RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' is set
> -Original Message- > From: Zhang, Yang Z > Sent: Friday, December 19, 2014 12:44 PM > To: Wu, Feng; Paolo Bonzini; k...@vger.kernel.org > Cc: io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; > k...@vger.kernel.org > Subject: RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' is set > > Wu, Feng wrote on 2014-12-19: > > > > > > Zhang, Yang Z wrote on 2014-12-19: > >> Subject: RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' is > >> set > >> > >> Wu, Feng wrote on 2014-12-19: > >>> > >>> > >>> iommu-boun...@lists.linux-foundation.org wrote on > >> mailto:iommu-boun...@lists.linux-foundation.org] On Behalf Of: > Cc: io...@lists.linux-foundation.org; > linux-kernel@vger.kernel.org; k...@vger.kernel.org > Subject: RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' > is set > > Paolo Bonzini wrote on 2014-12-18: > > > > > > On 18/12/2014 04:14, Wu, Feng wrote: > >> > >> > >> linux-kernel-ow...@vger.kernel.org wrote on > mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Paolo: > >>> x...@kernel.org; Gleb Natapov; Paolo Bonzini; > dw...@infradead.org; > >>> joro-zlv9swrftaidnm+yrof...@public.gmane.org; Alex Williamson; > >>> joro-zLv9SwRftAIdnm+Jiang Liu Cc: > >>> io...@lists.linux-foundation.org; > >>> linux-kernel-u79uwxl29ty76z2rm5m...@public.gmane.org; KVM > list; > >>> Eric Auger Subject: Re: [v3 25/26] KVM: Suppress posted-interrupt > >>> when 'SN' is set > >>> > >>> > >>> > >>> On 12/12/2014 16:14, Feng Wu wrote: > Currently, we don't support urgent interrupt, all interrupts > are recognized as non-urgent interrupt, so we cannot send > posted-interrupt when 'SN' is set. > >>> > >>> Can this happen? If the vcpu is in guest mode, it cannot have > >>> been scheduled out, and that's the only case when SN is set. > >>> > >>> Paolo > >> > >> Currently, the only place where SN is set is vCPU is preempted > >> and > > If the vCPU is preempted, shouldn't the subsequent be ignored? > What happens if a PI is occurs when vCPU is preempted? > >>> > >>> If a vCPU is preempted, the 'SN' bit is set, the subsequent > >>> interrupts are suppressed for posting. > >> > >> I mean what happens if we don't set SN bit. From my point, if > >> preempter already disabled the interrupt, it is ok to leave SN bit > >> as zero. But if preempter enabled the interrupt, doesn't this mean > >> he allow interrupt to happen? BTW, since there already has ON bit, > >> so this means there only have one interrupt arrived at most and it > >> doesn't hurt performance. Do we really need to set SN bit? > > > > > > See this scenario: > > vCPU0 is running on pCPU0 > > --> vCPU0 is preempted by vCPU1 > > --> Then vCPU1 is running on pCPU0 and vCPU0 is waiting for schedule > > --> in runqueue > > > > If the we don't set SN for vCPU0, then all subsequent interrupts for > > vCPU0 is posted to vCPU1, this will consume hardware and software > > The PI vector for vCPU1 is notification vector, but the PI vector for vCPU0 > should be wakeup vector. Why vCPU1 will consume this PI event? Wakeup vector is only used for blocking case, when vCPU is preempted and waiting in the runqueue, the NV is the notification vector. Thanks, Feng > > > efforts and in fact it is not needed at all. If SN is set for vCPU0, > > VT-d hardware will not issue Notification Event for vCPU0 when an > > interrupt is for it, but just setting the related PIR bit. > > > > Thanks, > > Feng > > > >> > >>> > >>> Thanks, > >>> Feng > >>> > > >> waiting for the next scheduling in the runqueue. But I am not > >> sure whether we need to set SN for other purpose in future. > >> Adding SN checking here is just to follow the Spec. non-urgent > >> interrupts are suppressed > > when SN is set. > > > > I would change that to a WARN_ON_ONCE then. > > > Best regards, > Yang > > > ___ > iommu mailing list > io...@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu > >> > >> > >> Best regards, > >> Yang > >> > > > Best regards, > Yang > -- 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: frequent lockups in 3.18rc4
On Thu, Dec 18, 2014 at 8:03 PM, Dave Jones wrote: > > So the only thing that was on that could cause spinlock overhead > was DEBUG_SPINLOCK (and LOCK_STAT, though iirc that's not huge either) So DEBUG_SPINLOCK does have one big downside if I recall correctly - the debugging spinlocks are very much not fair. So they don't work like the real ticket spinlocks. That might have serious effects on the contention case, with some thread not making any progress due to just the implementation of the debug spinlocks. Peter, Ingo, maybe I'm full of crap on the debug spinlock thing., but a quick look tells me thay are all built on top of the "trylock" primitive that does indeed not queue anything, and is thus not fair. I'm not sure why the debug spinlocks couldn't just be ticket locks instead. But there you are - once more, the debug infrastructure is actually much weaker and inferior to the "real" code. 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] Staging: rtl8192u: removed an unnecessary else statement
On 12/19/2014 04:08 AM, Jeremiah Mahler wrote:
Karthik,
On Thu, Dec 18, 2014 at 02:50:11PM +0530, Karthik Nayak wrote:
As per checkpatch warning, removed an unnecessary else statement
proceeding an if statement with a return.
Signed-off-by: Karthik Nayak
---
drivers/staging/rtl8192u/r8192U_dm.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_dm.c
b/drivers/staging/rtl8192u/r8192U_dm.c
index 936565d..b3b508c 100644
--- a/drivers/staging/rtl8192u/r8192U_dm.c
+++ b/drivers/staging/rtl8192u/r8192U_dm.c
@@ -480,15 +480,13 @@ static void dm_bandwidth_autoswitch(struct net_device
*dev)
if(priv->CurrentChannelBW == HT_CHANNEL_WIDTH_20 ||!priv->ieee80211->bandwidth_auto_switch.bautoswitch_enable){
return;
- }else{
- if(priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz ==
false){//If send packets in 40 Mhz in 20/40
- if(priv->undecorated_smoothed_pwdb <=
priv->ieee80211->bandwidth_auto_switch.threshold_40Mhzto20Mhz)
-
priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz = true;
- }else{//in force send packets in 20 Mhz in 20/40
- if(priv->undecorated_smoothed_pwdb >=
priv->ieee80211->bandwidth_auto_switch.threshold_20Mhzto40Mhz)
-
priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz = false;
-
- }
+ }
+ if(priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz ==
false){//If send packets in 40 Mhz in 20/40
+ if(priv->undecorated_smoothed_pwdb <=
priv->ieee80211->bandwidth_auto_switch.threshold_40Mhzto20Mhz)
+ priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz
= true;
+ }else{//in force send packets in 20 Mhz in 20/40
+ if(priv->undecorated_smoothed_pwdb >=
priv->ieee80211->bandwidth_auto_switch.threshold_20Mhzto40Mhz)
+ priv->ieee80211->bandwidth_auto_switch.bforced_tx20Mhz
= false;
}
} // dm_BandwidthAutoSwitch
[...]
Wow, I don't think I have ever seen a file with so many checkpatch errors!
Instead of only fixing one instance of one error I would fix all
instances of that type of error. Since the changes would be very
similar it should still be easy to review.
You could even make a whole patch series with each patch fixing one type
of error. Although I would keep the series to just a few at first until
you are sure you are doing everything right.
Hello Jeremiah,
I agree, there are a lot of errors, so I fixed a single issue.
This is just to get used to checkpatch system.
I can write patches to fix the other things, but I rather not.
I hope you get the point.
Regards
Karthik Nayak
--
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: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' is set
Wu, Feng wrote on 2014-12-19: > > > Zhang, Yang Z wrote on 2014-12-19: >> Subject: RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' is >> set >> >> Wu, Feng wrote on 2014-12-19: >>> >>> >>> iommu-boun...@lists.linux-foundation.org wrote on >> mailto:iommu-boun...@lists.linux-foundation.org] On Behalf Of: Cc: io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; k...@vger.kernel.org Subject: RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' is set Paolo Bonzini wrote on 2014-12-18: > > > On 18/12/2014 04:14, Wu, Feng wrote: >> >> >> linux-kernel-ow...@vger.kernel.org wrote on mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Paolo: >>> x...@kernel.org; Gleb Natapov; Paolo Bonzini; dw...@infradead.org; >>> joro-zlv9swrftaidnm+yrof...@public.gmane.org; Alex Williamson; >>> joro-zLv9SwRftAIdnm+Jiang Liu Cc: >>> io...@lists.linux-foundation.org; >>> linux-kernel-u79uwxl29ty76z2rm5m...@public.gmane.org; KVM list; >>> Eric Auger Subject: Re: [v3 25/26] KVM: Suppress posted-interrupt >>> when 'SN' is set >>> >>> >>> >>> On 12/12/2014 16:14, Feng Wu wrote: Currently, we don't support urgent interrupt, all interrupts are recognized as non-urgent interrupt, so we cannot send posted-interrupt when 'SN' is set. >>> >>> Can this happen? If the vcpu is in guest mode, it cannot have >>> been scheduled out, and that's the only case when SN is set. >>> >>> Paolo >> >> Currently, the only place where SN is set is vCPU is preempted >> and If the vCPU is preempted, shouldn't the subsequent be ignored? What happens if a PI is occurs when vCPU is preempted? >>> >>> If a vCPU is preempted, the 'SN' bit is set, the subsequent >>> interrupts are suppressed for posting. >> >> I mean what happens if we don't set SN bit. From my point, if >> preempter already disabled the interrupt, it is ok to leave SN bit >> as zero. But if preempter enabled the interrupt, doesn't this mean >> he allow interrupt to happen? BTW, since there already has ON bit, >> so this means there only have one interrupt arrived at most and it >> doesn't hurt performance. Do we really need to set SN bit? > > > See this scenario: > vCPU0 is running on pCPU0 > --> vCPU0 is preempted by vCPU1 > --> Then vCPU1 is running on pCPU0 and vCPU0 is waiting for schedule > --> in runqueue > > If the we don't set SN for vCPU0, then all subsequent interrupts for > vCPU0 is posted to vCPU1, this will consume hardware and software The PI vector for vCPU1 is notification vector, but the PI vector for vCPU0 should be wakeup vector. Why vCPU1 will consume this PI event? > efforts and in fact it is not needed at all. If SN is set for vCPU0, > VT-d hardware will not issue Notification Event for vCPU0 when an > interrupt is for it, but just setting the related PIR bit. > > Thanks, > Feng > >> >>> >>> Thanks, >>> Feng >>> >> waiting for the next scheduling in the runqueue. But I am not >> sure whether we need to set SN for other purpose in future. >> Adding SN checking here is just to follow the Spec. non-urgent >> interrupts are suppressed > when SN is set. > > I would change that to a WARN_ON_ONCE then. Best regards, Yang ___ iommu mailing list io...@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu >> >> >> Best regards, >> Yang >> Best regards, Yang -- 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: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' is set
> -Original Message- > From: Zhang, Yang Z > Sent: Friday, December 19, 2014 11:33 AM > To: Wu, Feng; Paolo Bonzini; k...@vger.kernel.org > Cc: io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; > k...@vger.kernel.org > Subject: RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' is set > > Wu, Feng wrote on 2014-12-19: > > > > > > iommu-boun...@lists.linux-foundation.org wrote on > mailto:iommu-boun...@lists.linux-foundation.org] On Behalf Of: > >> Cc: io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; > >> k...@vger.kernel.org > >> Subject: RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' is > >> set > >> > >> Paolo Bonzini wrote on 2014-12-18: > >>> > >>> > >>> On 18/12/2014 04:14, Wu, Feng wrote: > > > linux-kernel-ow...@vger.kernel.org wrote on > >> mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Paolo: > > x...@kernel.org; Gleb Natapov; Paolo Bonzini; > > dw...@infradead.org; > > joro-zlv9swrftaidnm+yrof...@public.gmane.org; Alex Williamson; > > joro-zLv9SwRftAIdnm+Jiang > > Liu > > Cc: io...@lists.linux-foundation.org; > > linux-kernel-u79uwxl29ty76z2rm5m...@public.gmane.org; KVM list; > > Eric Auger > > Subject: Re: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' > > is set > > > > > > > > On 12/12/2014 16:14, Feng Wu wrote: > >> Currently, we don't support urgent interrupt, all interrupts > >> are recognized as non-urgent interrupt, so we cannot send > >> posted-interrupt when 'SN' is set. > > > > Can this happen? If the vcpu is in guest mode, it cannot have > > been scheduled out, and that's the only case when SN is set. > > > > Paolo > > Currently, the only place where SN is set is vCPU is preempted > and > >> > >> If the vCPU is preempted, shouldn't the subsequent be ignored? What > >> happens if a PI is occurs when vCPU is preempted? > > > > If a vCPU is preempted, the 'SN' bit is set, the subsequent interrupts > > are suppressed for posting. > > I mean what happens if we don't set SN bit. From my point, if preempter > already disabled the interrupt, it is ok to leave SN bit as zero. But if > preempter > enabled the interrupt, doesn't this mean he allow interrupt to happen? BTW, > since there already has ON bit, so this means there only have one interrupt > arrived at most and it doesn't hurt performance. Do we really need to set SN > bit? See this scenario: vCPU0 is running on pCPU0 --> vCPU0 is preempted by vCPU1 --> Then vCPU1 is running on pCPU0 and vCPU0 is waiting for schedule in runqueue If the we don't set SN for vCPU0, then all subsequent interrupts for vCPU0 is posted to vCPU1, this will consume hardware and software efforts and in fact it is not needed at all. If SN is set for vCPU0, VT-d hardware will not issue Notification Event for vCPU0 when an interrupt is for it, but just setting the related PIR bit. Thanks, Feng > > > > > Thanks, > > Feng > > > >> > waiting for the next scheduling in the runqueue. But I am not > sure whether we need to set SN for other purpose in future. > Adding SN checking here is just to follow the Spec. non-urgent > interrupts are suppressed > >>> when SN is set. > >>> > >>> I would change that to a WARN_ON_ONCE then. > >> > >> > >> Best regards, > >> Yang > >> > >> > >> ___ > >> iommu mailing list > >> io...@lists.linux-foundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/iommu > > > Best regards, > Yang > -- 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/
PureMessage has encountered the following event(s): Virus infection detected
This sender alert message is generated by PureMessage because it has encountered the following events. Event(s): Virus infection detected Message action: Message quarantined Message ID: Subject: Mail Delivery (failure kullan...@domain.com) Sender: linux-kernel@vger.kernel.org Recipient(s): kullan...@domain.com Date: 12/18/2014 Time: 21:27:15 Job: Transport (SMTP) scanning Server: TPEEXET02 Incident information: Event: Virus infection detected Location: email body html Replaced with text: No Virus name(s): Mal/Iframe-E
[PATCH] audit: use supplied gfp_mask from audit_buffer in kauditd_send_multicast_skb
Eric Paris explains: Since kauditd_send_multicast_skb() gets called in
audit_log_end(), which can come from any context (aka even a sleeping context)
GFP_KERNEL can't be used. Since the audit_buffer knows what context it should
use, pass that down and use that.
See: https://lkml.org/lkml/2014/12/16/542
BUG: sleeping function called from invalid context at mm/slab.c:2849
in_atomic(): 1, irqs_disabled(): 0, pid: 885, name: sulogin
2 locks held by sulogin/885:
#0: (>cred_guard_mutex){+.+.+.}, at: []
prepare_bprm_creds+0x28/0x8b
#1: (tty_files_lock){+.+.+.}, at: []
selinux_bprm_committing_creds+0x55/0x22b
CPU: 1 PID: 885 Comm: sulogin Not tainted 3.18.0-next-20141216 #30
Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A15 06/20/2014
880223744f10 88022410f9b8 916ba529 0375
880223744f10 88022410f9e8 91063185 0006
88022410fa38
Call Trace:
[] dump_stack+0x50/0xa8
[] ___might_sleep+0x1b6/0x1be
[] __might_sleep+0x119/0x128
[] cache_alloc_debugcheck_before.isra.45+0x1d/0x1f
[] kmem_cache_alloc+0x43/0x1c9
[] __alloc_skb+0x42/0x1a3
[] skb_copy+0x3e/0xa3
[] audit_log_end+0x83/0x100
[] ? avc_audit_pre_callback+0x103/0x103
[] common_lsm_audit+0x441/0x450
[] slow_avc_audit+0x63/0x67
[] avc_has_perm+0xca/0xe3
[] inode_has_perm+0x5a/0x65
[] selinux_bprm_committing_creds+0x98/0x22b
[] security_bprm_committing_creds+0xe/0x10
[] install_exec_creds+0xe/0x79
[] load_elf_binary+0xe36/0x10d7
[] search_binary_handler+0x81/0x18c
[] do_execveat_common.isra.31+0x4e3/0x7b7
[] do_execve+0x1f/0x21
[] SyS_execve+0x25/0x29
[] stub_execve+0x69/0xa0
Cc: sta...@vger.kernel.org #v3.16-rc1
Reported-by: Valdis Kletnieks
Signed-off-by: Richard Guy Briggs
---
kernel/audit.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index 7b83c55..ce484fb 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -429,7 +429,7 @@ static void kauditd_send_skb(struct sk_buff *skb)
* This function doesn't consume an skb as might be expected since it has to
* copy it anyways.
*/
-static void kauditd_send_multicast_skb(struct sk_buff *skb)
+static void kauditd_send_multicast_skb(struct sk_buff *skb, gfp_t gfp_mask)
{
struct sk_buff *copy;
struct audit_net*aunet = net_generic(_net, audit_net_id);
@@ -448,11 +448,11 @@ static void kauditd_send_multicast_skb(struct sk_buff
*skb)
* no reason for new multicast clients to continue with this
* non-compliance.
*/
- copy = skb_copy(skb, GFP_KERNEL);
+ copy = skb_copy(skb, gfp_mask);
if (!copy)
return;
- nlmsg_multicast(sock, copy, 0, AUDIT_NLGRP_READLOG, GFP_KERNEL);
+ nlmsg_multicast(sock, copy, 0, AUDIT_NLGRP_READLOG, gfp_mask);
}
/*
@@ -1949,7 +1949,7 @@ void audit_log_end(struct audit_buffer *ab)
struct nlmsghdr *nlh = nlmsg_hdr(ab->skb);
nlh->nlmsg_len = ab->skb->len;
- kauditd_send_multicast_skb(ab->skb);
+ kauditd_send_multicast_skb(ab->skb, ab->gfp_mask);
/*
* The original kaudit unicast socket sends up messages with
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Thu, Dec 18, 2014 at 10:58:59PM -0500, Dave Jones wrote: > > lock debugging and other overheads (does this still have > > DEBUG_PAGEALLOC?) you really are getting into a "real" softlockup > > because things are scaling so horribly badly. > > > > If you now disable spinlock debugging and lockdep, hopefully that page > > table lock now doesn't always get hung up on the lockdep locking, so > > it starts scaling much better, and maybe you'd not see this... > > I can give it a shot. Hopefully there's some further mitigation that > could be done to allow a workload like this to survive under a debug > build though, as we've caught *so many* bugs with this stuff in the past. Turns out also that this build didn't have PROVE_LOCKING enabled. CONFIG_LOCKDEP was, but that just bloats the structures a little, and afaik doesn't incur the same runtime overhead. I also forgot to answer the question above, PAGEALLOC is also off. So the only thing that was on that could cause spinlock overhead was DEBUG_SPINLOCK (and LOCK_STAT, though iirc that's not huge either) 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: [PATCH net V2] net: drop the packet when fails to do software segmentation or header check
From: Jason Wang
Date: Fri, 19 Dec 2014 11:09:13 +0800
> Commit cecda693a969816bac5e470e1d9c9c0ef5567bca ("net: keep original skb
> which only needs header checking during software GSO") keeps the original
> skb for packets that only needs header check, but it doesn't drop the
> packet if software segmentation or header check were failed.
>
> Fixes cecda693a9 ("net: keep original skb which only needs header checking
> during software GSO")
>
> Cc: Eric Dumazet
> Signed-off-by: Jason Wang
Applied and queued up for -stable, thanks 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: frequent lockups in 3.18rc4
On Thu, Dec 18, 2014 at 07:49:41PM -0800, Linus Torvalds wrote: > And when spinlocks start getting contention, *nested* spinlocks > really really hurt. And you've got all the spinlock debugging on etc, > don't you? Yeah, though remember this seems to have for some reason gotten worse in more recent builds. I've been running kitchen-sink debug kernels for my trinity runs for the last three years, and it's only this last few months that this has got to be enough of a problem that I'm not seeing the more interesting bugs. (Or perhaps we're just getting better at fixing them in -next now, so my runs are lasting longer..) > Also, you do have this: > > sched: RT throttling activated > > so there's something going on with RT scheduling too. I see that fairly often. I've never dug into exactly what causes it, but it seems to be triggerable just by some long running CPU hogs. > So your printouts are finally starting to make sense. But I'm also > starting to suspect strongly that the problem is that with all your > lock debugging and other overheads (does this still have > DEBUG_PAGEALLOC?) you really are getting into a "real" softlockup > because things are scaling so horribly badly. > > If you now disable spinlock debugging and lockdep, hopefully that page > table lock now doesn't always get hung up on the lockdep locking, so > it starts scaling much better, and maybe you'd not see this... I can give it a shot. Hopefully there's some further mitigation that could be done to allow a workload like this to survive under a debug build though, as we've caught *so many* bugs with this stuff in the past. 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: [PATCH] checkpatch: Fix MAINTAINERS search pattern
On Fri, 2014-12-19 at 02:34 +, Chickles, Derek wrote: > > On Thu, 2014-12-18 at 12:12 -0800, Derek Chickles wrote: > > > This fixes the check that was supposed to prevent the MAINTAINERS > > > warning from appearing when you run checkpatch.pl on a patch that > > > includes new files/directories and an updated MAINTAINERS file. > > > > This suggested patch doesn't work. > > > > $realfile isn't set until the file shows up > > in the patch itself. > > > > The current test looks at the changelog > > before the files are modified and is correct. > > > > Thanks, you're right. My mistake was trying to run checkpatch.pl on a diff. > My patch works on diffs while the original code does not. This is by chance > really because MAINTAINERS is early in the patch. Using format-patch on > something that is committed is clearly the correct solution. Both tests can be used. Send another patch without deleting the first test and that'd be good to me. -- 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] Fixed TPACKET V3 to signal poll when block is closed rather than every packet
Make TPACKET_V3 signal poll when block is closed rather than for every
packet. Side effect is that poll will be signaled when block retire
timer expires which didn't previously happen. Issue was visible when
sending packets at a very low frequency such that all blocks are retired
before packets are received by TPACKET_V3. This caused avoidable packet
loss. The fix ensures that the signal is sent when blocks are closed
which covers the normal path where the block is filled as well as the
path where the timer expires. The case where a block is filled without
moving to the next block (ie. all blocks are full) will still cause poll
to be signaled.
Signed-off-by: Dan Collins
---
net/packet/af_packet.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index e52a447..6880f34 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -785,6 +785,7 @@ static void prb_close_block(struct tpacket_kbdq_core *pkc1,
struct tpacket3_hdr *last_pkt;
struct tpacket_hdr_v1 *h1 = >hdr.bh1;
+ struct sock *sk = >sk;
if (po->stats.stats3.tp_drops)
status |= TP_STATUS_LOSING;
@@ -809,6 +810,8 @@ static void prb_close_block(struct tpacket_kbdq_core *pkc1,
/* Flush the block */
prb_flush_block(pkc1, pbd1, status);
+ sk->sk_data_ready(sk);
+
pkc1->kactive_blk_num = GET_NEXT_PRB_BLK_NUM(pkc1);
}
@@ -2052,12 +2055,12 @@ static int tpacket_rcv(struct sk_buff *skb, struct
net_device *dev,
smp_wmb();
#endif
- if (po->tp_version <= TPACKET_V2)
+ if (po->tp_version <= TPACKET_V2) {
__packet_set_status(po, h.raw, status);
- else
+ sk->sk_data_ready(sk);
+ } else {
prb_clear_blk_fill_status(>rx_ring);
-
- sk->sk_data_ready(sk);
+ }
drop_n_restore:
if (skb_head != skb->data && skb_shared(skb)) {
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Thu, Dec 18, 2014 at 6:45 PM, Dave Jones wrote: > > Example of the spew-o-rama below. Hmm. Not only does it apparently stay up for you now, the traces seem to be improving in quality. There's a decided pattern of "copy_page_range()" and "zap_page_range()" here. Now, what's *also* intriguing is how many "_raw_spin_lock_nested" things there are in there. Which makes me suspect that you are actually hitting some really nasty spinlock contention, and that your 22s lockups could be due to lock hold times going exponential. So I don't think that it's the copy_page_range() itself that is necessarily all that horribly expensive (although it's certainly not a lightweight function), but the fact that you get contention on some lock inside that loop, and when you have every single CPU hammering on it things just go to hell in a handbasket. And when spinlocks start getting contention, *nested* spinlocks really really hurt. And you've got all the spinlock debugging on etc, don't you? Which just makes the locks really expensive, and much much easier to start becoming contended (and there's *another* level of nesting, because I think the lockdep stuff has its own locking inside). So you have three levels of spinlock nesting, and the outer one will be completely hammered. So I think the locks you have are from copy_pte_range: dst_pte = pte_alloc_map_lock(dst_mm, dst_pmd, addr, _ptl); if (!dst_pte) return -ENOMEM; src_pte = pte_offset_map(src_pmd, addr); src_ptl = pte_lockptr(src_mm, src_pmd); spin_lock_nested(src_ptl, SINGLE_DEPTH_NESTING); and we do have some mitigation in place for horrible horrible contention (try to release every few entries, but with all CPU's hammering on these locks, and things being slow due to all the debugging, I think we may finally be hitting the right place here. Also, you do have this: sched: RT throttling activated so there's something going on with RT scheduling too. I'd consider all the softlockups after that point suspect - the softlockup thread has presumably used so much CPU spewing out the debug messages that things aren't really working any more RT-wise. Lookie here (the "soft lockup" grep is to skip all the cross-CPU traces from other CPU's that weren't necessarily the problem case): [torvalds@i7 linux]$ grep -5 "soft lockup" ~/0.txt | grep RIP RIP: 0010: lock_acquire+0xb4/0x120 RIP: 0010: lock_acquire+0xb4/0x120 RIP: 0010: generic_exec_single+0xee/0x1b0 RIP: 0010: lock_acquire+0xb4/0x120 RIP: 0010: lock_acquire+0xb4/0x120 RIP: 0010: lock_acquire+0xb4/0x120 RIP: 0010: lock_acquire+0xb4/0x120 RIP: 0010: lock_acquire+0xb4/0x120 RIP: 0010: lock_acquire+0xb4/0x120 RIP: 0010: shmem_write_end+0x65/0xf0 RIP: 0010: _raw_spin_unlock_irqrestore+0x38/0x60 RIP: 0010: copy_user_enhanced_fast_string+0x5/0x10 RIP: 0010: copy_user_enhanced_fast_string+0x5/0x10 RIP: 0010: __slab_alloc+0x52f/0x58f RIP: 0010: map_id_up+0x9/0x80 RIP: 0010: cpuidle_enter_state+0x79/0x190 RIP: 0010: unmap_single_vma+0x7d9/0x900 RIP: 0010: cpuidle_enter_state+0x79/0x190 and notice the pattern? All those early RIP cases are the page table locks for copy_page_range and that one TLB flush for zap_page_range.. So your printouts are finally starting to make sense. But I'm also starting to suspect strongly that the problem is that with all your lock debugging and other overheads (does this still have DEBUG_PAGEALLOC?) you really are getting into a "real" softlockup because things are scaling so horribly badly. If you now disable spinlock debugging and lockdep, hopefully that page table lock now doesn't always get hung up on the lockdep locking, so it starts scaling much better, and maybe you'd not see this... 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/
net: ucc: tbi phy detection broken by 058112c7efc9ef43bb511c137293dddbe6e42908
I have been trying to move an 8360 based system from a 3.0 kernel to a 3.12 (on the way to 3.14 with ipipe/xenomai) kernel and encountered an oops in the ucc_geth driver when using RTBI mode on one of the ucc ports. I haven't managed to find any commits to of_mdio or ucc_geth or fsl_pq_mdio that would appear to address this problem, so I believe it is still present in the latest kernel, but have not confirmed that with testing yet. Commit 058112c7efc9ef43bb511c137293dddbe6e42908 appears to have broken ucc support for tbi phy detection. With the patch in place, I am unable to get the mdio bus to create phy devices for the tbi phy in the ucc on an 8360e, and the ucc_geth driver causes a kernel oops, while with the patch reverted, it does create them and the driver comes up and works. The tbi phy is needed when using a ucc in RTBI, TBI or SGMII mode. I am not convinced that the tbi phy really behaves quite like a real phy, which may be why get_phy_device does not work with it. Perhaps there is a better way to deal with the tbi phy on the ucc for this purpose. Certainly as it is, this patch has caused a regression though, although probably not very many systems with ucc ports actually use one of the affected modes so the damage isn't that great. -- Len Sorensen -- 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] Fixed TPACKET V3 to signal poll when block is closed rather than every packet
From: Dan Collins Date: Fri, 19 Dec 2014 13:32:19 +1300 > + * Dan Collins : Fixed TPACKET_V3 to wake poll when block is closed > + * rather than for every packet. Since we now use real version control with commit messages, this comment at the top of the source file is not an appropriate place to log your change. -- 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: Re: [PATCHv7 1/3] kernel: add TAINT_LIVEPATCH
(2014/12/19 0:52), Jiri Kosina wrote: > On Thu, 18 Dec 2014, Masami Hiramatsu wrote: > >>> This adds a new taint flag to indicate when the kernel or a kernel >>> module has been live patched. This will provide a clean indication in >>> bug reports that live patching was used. >>> >>> Additionally, if the crash occurs in a live patched function, the live >>> patch module will appear beside the patched function in the backtrace. >>> >>> Signed-off-by: Seth Jennings >> >> Looks good to me. >> >> Reviewed-by: Masami Hiramatsu > > Masami, just for completness -- is this just for 1/3, or for the whole > series? (so that I get it right once I am applying the patches to git > tree). Yeah, Now all the patches in this series are OK to me :) Feel free to add my Reviewed-by. Reviewed-by: Masami Hiramatsu for this series :) Thank you! > > Thanks, > -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] livepatch: use FTRACE_OPS_FL_IPMODIFY
(2014/12/19 0:49), Josh Poimboeuf wrote: > On Thu, Dec 18, 2014 at 08:55:21PM +0900, Masami Hiramatsu wrote: >> (2014/12/17 2:58), Seth Jennings wrote: >>> changes in v7: >>> - TODO: set IPMODIFY (not a blocker to moving forward) >> >> Why don't you set this? >> IPMODIFY series are not completely applied yet, but you can already >> use the flag. All you need is just set it :) > > Yeah, I don't see any reason why we can't start using this flag now. > How about we add this patch to the queue? > > -->8-- > > Subject: livepatch: use FTRACE_OPS_FL_IPMODIFY > > Use the FTRACE_OPS_FL_IPMODIFY flag to prevent conflicts with other > ftrace users who also modify regs->ip. > > Signed-off-by: Josh Poimboeuf Looks good to me :) Acked-by: Masami Hiramatsu Thanks! > --- > kernel/livepatch/core.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c > index 0004a71..bdd99975 100644 > --- a/kernel/livepatch/core.c > +++ b/kernel/livepatch/core.c > @@ -640,7 +640,8 @@ static int klp_init_func(struct klp_object *obj, struct > klp_func *func) > > ops->private = func; > ops->func = klp_ftrace_handler; > - ops->flags = FTRACE_OPS_FL_SAVE_REGS | FTRACE_OPS_FL_DYNAMIC; > + ops->flags = FTRACE_OPS_FL_SAVE_REGS | FTRACE_OPS_FL_DYNAMIC | > + FTRACE_FL_IPMODIFY; > func->fops = ops; > func->state = KLP_DISABLED; > > -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' is set
Wu, Feng wrote on 2014-12-19: > > > iommu-boun...@lists.linux-foundation.org wrote on > mailto:iommu-boun...@lists.linux-foundation.org] On Behalf Of: >> Cc: io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; >> k...@vger.kernel.org >> Subject: RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' is >> set >> >> Paolo Bonzini wrote on 2014-12-18: >>> >>> >>> On 18/12/2014 04:14, Wu, Feng wrote: linux-kernel-ow...@vger.kernel.org wrote on >> mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Paolo: > x...@kernel.org; Gleb Natapov; Paolo Bonzini; > dw...@infradead.org; > joro-zlv9swrftaidnm+yrof...@public.gmane.org; Alex Williamson; > joro-zLv9SwRftAIdnm+Jiang > Liu > Cc: io...@lists.linux-foundation.org; > linux-kernel-u79uwxl29ty76z2rm5m...@public.gmane.org; KVM list; > Eric Auger > Subject: Re: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' > is set > > > > On 12/12/2014 16:14, Feng Wu wrote: >> Currently, we don't support urgent interrupt, all interrupts >> are recognized as non-urgent interrupt, so we cannot send >> posted-interrupt when 'SN' is set. > > Can this happen? If the vcpu is in guest mode, it cannot have > been scheduled out, and that's the only case when SN is set. > > Paolo Currently, the only place where SN is set is vCPU is preempted and >> >> If the vCPU is preempted, shouldn't the subsequent be ignored? What >> happens if a PI is occurs when vCPU is preempted? > > If a vCPU is preempted, the 'SN' bit is set, the subsequent interrupts > are suppressed for posting. I mean what happens if we don't set SN bit. From my point, if preempter already disabled the interrupt, it is ok to leave SN bit as zero. But if preempter enabled the interrupt, doesn't this mean he allow interrupt to happen? BTW, since there already has ON bit, so this means there only have one interrupt arrived at most and it doesn't hurt performance. Do we really need to set SN bit? > > Thanks, > Feng > >> waiting for the next scheduling in the runqueue. But I am not sure whether we need to set SN for other purpose in future. Adding SN checking here is just to follow the Spec. non-urgent interrupts are suppressed >>> when SN is set. >>> >>> I would change that to a WARN_ON_ONCE then. >> >> >> Best regards, >> Yang >> >> >> ___ >> iommu mailing list >> io...@lists.linux-foundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/iommu Best regards, Yang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] acpi: Add "acpi_osi=" for ASUS X200MA to enable, brightness keys
On 12/19/2014 09:46 AM, Aaron Lu wrote:
> CC Jani, who is working on the patchset to enable 8+ output devices and
> may have some comments on this.
Change Jani's email address, I got a warning from the mailer about his other
email address.
>
> Regards,
> Aaron
>
> On 12/18/2014 09:25 PM, Josh Boyer wrote:
>> On Thu, Dec 18, 2014 at 7:16 AM, Dmitry Tunin
>> wrote:
>>> Add "acpi_osi=" quirk for ASUS X200MA
>>> More information can be found in UX302LA bugreport
>>> https://bugzilla.kernel.org/show_bug.cgi?id=70241
>>>
>>> X200MA is affected by th e same bug and the solution has been tested
>>>
>>> I reported it to launchpad too
>>> https://bugs.launchpad.net/ubuntu/bug/1400068
>>>
>>> Cc: sta...@vger.kernel.org
>>> Signed-off-by: Dmitry Tunin
>>>
>>
>> The UX301LA models have the same setup, with 16 devices instead of 8.
>> I discussed this with Matthew Garrett a bit and a more ideal approach
>> is to actually enumerate all 16 devices between the firmware and i915
>> driver. The problem we have is that the intel opregion spec that
>> hasn't been updated since 2008 doesn't cover the additional 8 devices.
>> Anyway, that is being tracked here:
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=81762
>>
>>> ---
>>> drivers/acpi/blacklist.c | 20
>>> 1 file changed, 20 insertions(+)
>>>
>>> diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
>>> index 7556e7c..f78ed08 100644
>>> --- a/drivers/acpi/blacklist.c
>>> +++ b/drivers/acpi/blacklist.c
>>> @@ -162,6 +162,17 @@ static int __init dmi_disable_osi_win8(const struct
>>> dmi_system_id *d)
>>> acpi_osi_setup("!Windows 2012");
>>> return 0;
>>> }
>>> +/*
>>> + * Some ASUS models firmware declares 16 devices instead of 8
>>> + * 'acpi_osi=' kernel parameter fixes it
>>> + * Without this parameters brightness keys Fn+F5 and F6 do not work
>>> + */
>>> +static int __init dmi_disable_osi_all(const struct dmi_system_id *d)
>>> +{
>>> + printk(KERN_NOTICE PREFIX "DMI detected: %s\n", d->ident);
>>> + acpi_osi_setup("");
>>> + return 0;
>>> +}
>>
>> What does this do to the rest of the function keys? Does everything
>> else still work as expected, including suspend and resume?
>>
>>> static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
>>> {
>>> @@ -371,6 +382,15 @@ static struct dmi_system_id acpi_osi_dmi_table[]
>>> __initdata = {
>>> DMI_MATCH(DMI_PRODUCT_NAME, "1015PX"),
>>> },
>>> },
>>> + /* Without this brightness keys do not work */
>>> + {
>>> + .callback = dmi_disable_osi_all,
>>> + .ident = "ASUSTeK COMPUTER INC. X200MA",
>>> + .matches = {
>>> +DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
>>> +DMI_MATCH(DMI_PRODUCT_NAME, "X200MA"),
>>> + },
>>> + },
>>> {}
>>> };
>>>
>>> --
>>> 1.9.1
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe stable" 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/
[PATCH net V2] net: drop the packet when fails to do software segmentation or header check
Commit cecda693a969816bac5e470e1d9c9c0ef5567bca ("net: keep original skb
which only needs header checking during software GSO") keeps the original
skb for packets that only needs header check, but it doesn't drop the
packet if software segmentation or header check were failed.
Fixes cecda693a9 ("net: keep original skb which only needs header checking
during software GSO")
Cc: Eric Dumazet
Signed-off-by: Jason Wang
---
Stable candidate for 3.17 and above.
Changes from V1:
- Fix fixes tag
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index f411c28..a989f85 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2673,7 +2673,7 @@ static struct sk_buff *validate_xmit_skb(struct sk_buff
*skb, struct net_device
segs = skb_gso_segment(skb, features);
if (IS_ERR(segs)) {
- segs = NULL;
+ goto out_kfree_skb;
} else if (segs) {
consume_skb(skb);
skb = segs;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net] net: drop the packet when fails to do software segmentation or header check
On Fri, Dec 19, 2014 at 4:39 AM, David Miller
wrote:
From: Jason Wang
Date: Thu, 18 Dec 2014 13:57:19 +0800
Fixes cecda693a969816bac5e470e1d9c9c0ef5567bca
Please correct this fixes tag, it should be of the form:
Fixes: $(SHA1) ("header text of commit message")
The SHA1 ID should be reduced to 12 digits of significance.
Ok, will post V2.
--
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: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' is set
> -Original Message- > From: iommu-boun...@lists.linux-foundation.org > [mailto:iommu-boun...@lists.linux-foundation.org] On Behalf Of Zhang, Yang Z > Sent: Thursday, December 18, 2014 11:10 PM > To: Paolo Bonzini; k...@vger.kernel.org > Cc: io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; > k...@vger.kernel.org > Subject: RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' is set > > Paolo Bonzini wrote on 2014-12-18: > > > > > > On 18/12/2014 04:14, Wu, Feng wrote: > >> > >> > >> linux-kernel-ow...@vger.kernel.org wrote on > mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Paolo: > >>> x...@kernel.org; Gleb Natapov; Paolo Bonzini; dw...@infradead.org; > >>> joro-zlv9swrftaidnm+yrof...@public.gmane.org; Alex Williamson; > >>> joro-zLv9SwRftAIdnm+Jiang > >>> Liu > >>> Cc: io...@lists.linux-foundation.org; > >>> linux-kernel-u79uwxl29ty76z2rm5m...@public.gmane.org; KVM list; > >>> Eric Auger > >>> Subject: Re: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' is > >>> set > >>> > >>> > >>> > >>> On 12/12/2014 16:14, Feng Wu wrote: > Currently, we don't support urgent interrupt, all interrupts are > recognized as non-urgent interrupt, so we cannot send > posted-interrupt when 'SN' is set. > >>> > >>> Can this happen? If the vcpu is in guest mode, it cannot have been > >>> scheduled out, and that's the only case when SN is set. > >>> > >>> Paolo > >> > >> Currently, the only place where SN is set is vCPU is preempted and > > If the vCPU is preempted, shouldn't the subsequent be ignored? What happens > if a PI is occurs when vCPU is preempted? If a vCPU is preempted, the 'SN' bit is set, the subsequent interrupts are suppressed for posting. Thanks, Feng > > >> waiting for the next scheduling in the runqueue. But I am not sure > >> whether we need to set SN for other purpose in future. Adding SN > >> checking here is just to follow the Spec. non-urgent interrupts are > >> suppressed > > when SN is set. > > > > I would change that to a WARN_ON_ONCE then. > > > Best regards, > Yang > > > ___ > iommu mailing list > io...@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu -- 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: [v3 24/26] KVM: Update Posted-Interrupts Descriptor when vCPU is blocked
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Paolo Bonzini
> Sent: Thursday, December 18, 2014 4:37 PM
> To: linux-kernel@vger.kernel.org
> Cc: io...@lists.linux-foundation.org; k...@vger.kernel.org;
> linux-kernel@vger.kernel.org; k...@vger.kernel.org
> Subject: Re: [v3 24/26] KVM: Update Posted-Interrupts Descriptor when vCPU
> is blocked
>
>
>
> On 18/12/2014 04:16, Wu, Feng wrote:
> >>> pre-block:
> >>> - Add the vCPU to the blocked per-CPU list
> >>> - Clear 'SN'
> >>
> >> Should SN be already clear (and NV set to POSTED_INTR_VECTOR)?
> >
> > I think the SN bit should be clear here, Adding it here is just to make sure
> > SN is clear when vCPU is blocked, so it can receive wakeup notification
> > event
> later.
>
> Then, please, WARN if the SN bit is set inside the if (vcpu->blocked).
> Inside that if you can just add the vCPU to the blocked list on vcpu_put.
>
> >> Can it
> >> happen that you go from sched-out to blocked without doing a sched-in
> first?
> >>
> >
> > I cannot imagine this scenario, can you please be more specific? Thanks a
> > lot!
>
> I cannot either. :) But it would be the case where SN is not cleared.
> So we agree that it cannot happen.
>
> >> In fact, if this is possible, what happens if vcpu->preempted &&
> >> vcpu->blocked?
> >
> > In fact, vcpu->preempted && vcpu->blocked happens sometimes, but I think
> there is
> > no issues. Please refer to the following case:
>
> I agree that there should be no issues. But if it can happen, it's better:
>
> 1) to separate the handling of preemption and blocking: preemption
> handles SN/NV/NDST, blocking handles the wakeup list.
>
Sorry, I don't quite understand this.
I think handling of preemption and blocking is separated in vmx_vcpu_put().
For vmx_vcpu_load(), the handling of SN/NV/NDST is common for preemption
and blocking.
Thanks,
Feng
> 2) to change this
>
> + } else if (vcpu->blocked) {
> + /*
> + * The vcpu is blocked on the wait queue.
> + * Store the blocked vCPU on the list of the
> + * vcpu->wakeup_cpu, which is the destination
> + * of the wake-up notification event.
>
> to just
>
> }
> if (vcpu->blocked) {
> ...
> }
> > kvm_vcpu_block()
> > -> vcpu->blocked = true;
> > -> prepare_to_wait(>wq, , TASK_INTERRUPTIBLE);
> >
> > before schedule() is called, this vcpu is woken up by another guy, so
> > the state of the vcpu associated thread is changed to TASK_RUNNING,
> > then preemption happens after interrupts or the following schedule() is
> > hit, this will call kvm_sched_out(), in which current->state ==
> TASK_RUNNING
> > and vcpu->preempted is set to true. So now vcpu->preempted and
> vcpu->blocked
> > are both true. In vmx_vcpu_put(), we will check vcpu->preempted first,
> > so
> > the vCPU will not be blocked, and the vcpu->blocked will be set the
> > false in
> > vmx_vcpu_load().
> >
> > But maybe I need do a little change to the vmx_vcpu_load() like below:
> >
> > /*
> > * Delete the vCPU from the related wakeup queue
> > * if we are resuming from blocked state
> > */
> > if (vcpu->blocked) {
> > vcpu->blocked = false;
> > + /* if wakeup_cpu == -1, the
> > vcpu is currently not
> blocked on any
> > + pCPU, don't need dequeue here
> > */
> > + if (vcpu->wakeup_cpu != -1) {
> >
> spin_lock_irqsave(_cpu(blocked_vcpu_on_cpu_lock,
> > vcpu->wakeup_cpu), flags);
> > list_del(>blocked_vcpu_list);
> >
> spin_unlock_irqrestore(_cpu(blocked_vcpu_on_cpu_lock,
> > vcpu->wakeup_cpu), flags);
> > vcpu->wakeup_cpu = -1;
> > + }
> > }
>
> Good idea.
>
> Paolo
>
> > Any ideas about this? Thanks a lot!
> >
> > Thanks,
> > Feng
> >
> >
> > -> schedule();
> >
> >
> >>
> >>> - Set 'NV' to POSTED_INTR_WAKEUP_VECTOR
> >>>
> >>> post-block:
> >>> - Remove the vCPU from the per-CPU list
> >>
> >> Paolo
> >>
> >>> Signed-off-by: Feng Wu
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe kvm" 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/
--
[PATCH RESEND v2 02/10] power: charger-manager: Use power_supply_changed() not private uevent.
Whenever battery status is changed, charger manager tries to trigger uevent
through private interface. This patch modifies it to use power_supply_changed()
since it belongs to power supply subsystem.
Signed-off-by: Jonghwa Lee
---
drivers/power/charger-manager.c | 91 +--
1 file changed, 11 insertions(+), 80 deletions(-)
diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index b4b101c..33a1a4d 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -28,18 +28,6 @@
#include
#include
-static const char * const default_event_names[] = {
- [CM_EVENT_UNKNOWN] = "Unknown",
- [CM_EVENT_BATT_FULL] = "Battery Full",
- [CM_EVENT_BATT_IN] = "Battery Inserted",
- [CM_EVENT_BATT_OUT] = "Battery Pulled Out",
- [CM_EVENT_BATT_OVERHEAT] = "Battery Overheat",
- [CM_EVENT_BATT_COLD] = "Battery Cold",
- [CM_EVENT_EXT_PWR_IN_OUT] = "External Power Attach/Detach",
- [CM_EVENT_CHG_START_STOP] = "Charging Start/Stop",
- [CM_EVENT_OTHERS] = "Other battery events"
-};
-
/*
* Regard CM_JIFFIES_SMALL jiffies is small enough to ignore for
* delayed works so that we can run delayed works with CM_JIFFIES_SMALL
@@ -56,8 +44,6 @@ static const char * const default_event_names[] = {
*/
#define CM_RTC_SMALL (2)
-#define UEVENT_BUF_SIZE32
-
static LIST_HEAD(cm_list);
static DEFINE_MUTEX(cm_list_mtx);
@@ -423,61 +409,6 @@ static int try_charger_restart(struct charger_manager *cm)
}
/**
- * uevent_notify - Let users know something has changed.
- * @cm: the Charger Manager representing the battery.
- * @event: the event string.
- *
- * If @event is null, it implies that uevent_notify is called
- * by resume function. When called in the resume function, cm_suspended
- * should be already reset to false in order to let uevent_notify
- * notify the recent event during the suspend to users. While
- * suspended, uevent_notify does not notify users, but tracks
- * events so that uevent_notify can notify users later after resumed.
- */
-static void uevent_notify(struct charger_manager *cm, const char *event)
-{
- static char env_str[UEVENT_BUF_SIZE + 1] = "";
- static char env_str_save[UEVENT_BUF_SIZE + 1] = "";
-
- if (cm_suspended) {
- /* Nothing in suspended-event buffer */
- if (env_str_save[0] == 0) {
- if (!strncmp(env_str, event, UEVENT_BUF_SIZE))
- return; /* status not changed */
- strncpy(env_str_save, event, UEVENT_BUF_SIZE);
- return;
- }
-
- if (!strncmp(env_str_save, event, UEVENT_BUF_SIZE))
- return; /* Duplicated. */
- strncpy(env_str_save, event, UEVENT_BUF_SIZE);
- return;
- }
-
- if (event == NULL) {
- /* No messages pending */
- if (!env_str_save[0])
- return;
-
- strncpy(env_str, env_str_save, UEVENT_BUF_SIZE);
- kobject_uevent(>dev->kobj, KOBJ_CHANGE);
- env_str_save[0] = 0;
-
- return;
- }
-
- /* status not changed */
- if (!strncmp(env_str, event, UEVENT_BUF_SIZE))
- return;
-
- /* save the status and notify the update */
- strncpy(env_str, event, UEVENT_BUF_SIZE);
- kobject_uevent(>dev->kobj, KOBJ_CHANGE);
-
- dev_info(cm->dev, "%s\n", event);
-}
-
-/**
* fullbatt_vchk - Check voltage drop some times after "FULL" event.
* @work: the work_struct appointing the function
*
@@ -514,7 +445,7 @@ static void fullbatt_vchk(struct work_struct *work)
if (diff > desc->fullbatt_vchkdrop_uV) {
try_charger_restart(cm);
- uevent_notify(cm, "Recharging");
+ power_supply_changed(>charger_psy);
}
}
@@ -545,7 +476,7 @@ static int check_charging_duration(struct charger_manager
*cm)
if (duration > desc->charging_max_duration_ms) {
dev_info(cm->dev, "Charging duration exceed %ums\n",
desc->charging_max_duration_ms);
- uevent_notify(cm, "Discharging");
+ power_supply_changed(>charger_psy);
try_charger_enable(cm, false);
ret = true;
}
@@ -556,7 +487,7 @@ static int check_charging_duration(struct charger_manager
*cm)
is_ext_pwr_online(cm)) {
dev_info(cm->dev, "Discharging duration exceed %ums\n",
desc->discharging_max_duration_ms);
- uevent_notify(cm, "Recharging");
+ power_supply_changed(>charger_psy);
try_charger_enable(cm, true);
ret
[PATCH RESEND v2 07/10] power: charger-manager: Make chraging decision focusing on battery status.
In cm_monitor() where charging management starts, it checks various charging
condition sequentially to decide next charging operation. However, as it
follows sequential process, cascaded IF statements, it does some duplicated
jobs which is already done in previous stage. It results delay in decision
making. And moreover, starting point of charing is spreaded all around, so
it makes maintain codes and debugging difficult.
Both of problems mentioned above becomes clean if it manages battery charging
focusing on battery status not following sequential condition checking.
Now, cm_monitor() moves battery state diagram and does optimal operation for
current state. As a result, it reduces whole monitoring time almost in half.
Signed-off-by: Jonghwa Lee
---
drivers/power/charger-manager.c | 177 +++--
include/linux/power/charger-manager.h |3 +
2 files changed, 62 insertions(+), 118 deletions(-)
diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index 172dfe5..065b92a 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -249,6 +249,19 @@ static bool is_full_charged(struct charger_manager *cm)
if (!fuel_gauge)
return false;
+ /* Full, if it's over the fullbatt voltage */
+ if (desc->fullbatt_uV > 0) {
+ ret = get_batt_uV(cm, );
+ if (!ret) {
+ /* Battery is already full, checks voltage drop. */
+ if (cm->battery_status == POWER_SUPPLY_STATUS_FULL
+ && desc->fullbatt_vchkdrop_uV)
+ uV += desc->fullbatt_vchkdrop_uV;
+ if (uV >= desc->fullbatt_uV)
+ return true;
+ }
+ }
+
if (desc->fullbatt_full_capacity > 0) {
val.intval = 0;
@@ -259,13 +272,6 @@ static bool is_full_charged(struct charger_manager *cm)
return true;
}
- /* Full, if it's over the fullbatt voltage */
- if (desc->fullbatt_uV > 0) {
- ret = get_batt_uV(cm, );
- if (!ret && uV >= desc->fullbatt_uV)
- return true;
- }
-
/* Full, if the capacity is more than fullbatt_soc */
if (desc->fullbatt_soc > 0) {
val.intval = 0;
@@ -376,67 +382,13 @@ static int try_charger_enable(struct charger_manager *cm,
bool enable)
}
}
- if (!err) {
+ if (!err)
cm->charger_enabled = enable;
- power_supply_changed(>charger_psy);
- }
return err;
}
/**
- * try_charger_restart - Restart charging.
- * @cm: the Charger Manager representing the battery.
- *
- * Restart charging by turning off and on the charger.
- */
-static int try_charger_restart(struct charger_manager *cm)
-{
- int err;
-
- if (cm->emergency_stop)
- return -EAGAIN;
-
- err = try_charger_enable(cm, false);
- if (err)
- return err;
-
- return try_charger_enable(cm, true);
-}
-
-/**
- * fullbatt_vchk - Check voltage drop some times after "FULL" event.
- *
- * If a user has designated "fullbatt_vchkdrop_uV" values with
- * charger_desc, Charger Manager checks voltage drop after the battery
- * "FULL" event. It checks whether the voltage has dropped more than
- * fullbatt_vchkdrop_uV by calling this function after fullbatt_vchkrop_ms.
- */
-static void fullbatt_vchk(struct charger_manager *cm)
-{
- struct charger_desc *desc = cm->desc;
- int batt_uV, err, diff;
-
- if (!desc->fullbatt_vchkdrop_uV)
- return;
-
- err = get_batt_uV(cm, _uV);
- if (err) {
- dev_err(cm->dev, "%s: get_batt_uV error(%d)\n", __func__, err);
- return;
- }
-
- diff = desc->fullbatt_uV - batt_uV;
- if (diff < 0)
- return;
-
- dev_info(cm->dev, "VBATT dropped %duV after full-batt\n", diff);
-
- if (diff > desc->fullbatt_vchkdrop_uV)
- try_charger_restart(cm);
-}
-
-/**
* check_charging_duration - Monitor charging/discharging duration
* @cm: the Charger Manager representing the battery.
*
@@ -463,17 +415,14 @@ static int check_charging_duration(struct charger_manager
*cm)
if (duration > desc->charging_max_duration_ms) {
dev_info(cm->dev, "Charging duration exceed %ums\n",
desc->charging_max_duration_ms);
- try_charger_enable(cm, false);
ret = true;
}
- } else if (is_ext_pwr_online(cm) && !cm->charger_enabled) {
+ } else if (cm->battery_status == POWER_SUPPLY_STATUS_NOT_CHARGING) {
duration = curr - cm->charging_end_time;
- if (duration > desc->charging_max_duration_ms &&
-
[PATCH RESEND v2 01/10] power: charger-manager: Use thermal subsystem interface only to get temperature.
It drops the way of using power_supply interface to reference battery's
temperature. Then it tries to use thermal subsystem's only. This makes driver
more simple and also can remove ifdeferies.
Signed-off-by: Jonghwa Lee
---
drivers/power/Kconfig |1 +
drivers/power/charger-manager.c | 113 -
include/linux/power/charger-manager.h |3 +-
3 files changed, 28 insertions(+), 89 deletions(-)
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 8ff2511..115d153 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -317,6 +317,7 @@ config CHARGER_MANAGER
bool "Battery charger manager for multiple chargers"
depends on REGULATOR
select EXTCON
+ select THERMAL
help
Say Y to enable charger-manager support, which allows multiple
chargers attached to a battery and multiple batteries attached to a
diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index 22246b9..b4b101c 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -28,13 +28,6 @@
#include
#include
-/*
- * Default termperature threshold for charging.
- * Every temperature units are in tenth of centigrade.
- */
-#define CM_DEFAULT_RECHARGE_TEMP_DIFF 50
-#define CM_DEFAULT_CHARGE_TEMP_MAX 500
-
static const char * const default_event_names[] = {
[CM_EVENT_UNKNOWN] = "Unknown",
[CM_EVENT_BATT_FULL] = "Battery Full",
@@ -572,40 +565,18 @@ static int check_charging_duration(struct charger_manager
*cm)
return ret;
}
-static int cm_get_battery_temperature_by_psy(struct charger_manager *cm,
- int *temp)
-{
- struct power_supply *fuel_gauge;
-
- fuel_gauge = power_supply_get_by_name(cm->desc->psy_fuel_gauge);
- if (!fuel_gauge)
- return -ENODEV;
-
- return fuel_gauge->get_property(fuel_gauge,
- POWER_SUPPLY_PROP_TEMP,
- (union power_supply_propval *)temp);
-}
-
static int cm_get_battery_temperature(struct charger_manager *cm,
int *temp)
{
int ret;
- if (!cm->desc->measure_battery_temp)
+ if (!cm->tzd_batt)
return -ENODEV;
-#ifdef CONFIG_THERMAL
- if (cm->tzd_batt) {
- ret = thermal_zone_get_temp(cm->tzd_batt, (unsigned long
*)temp);
- if (!ret)
- /* Calibrate temperature unit */
- *temp /= 100;
- } else
-#endif
- {
- /* if-else continued from CONFIG_THERMAL */
- ret = cm_get_battery_temperature_by_psy(cm, temp);
- }
+ ret = thermal_zone_get_temp(cm->tzd_batt, (unsigned long *)temp);
+ if (!ret)
+ /* Calibrate temperature unit */
+ *temp /= 100;
return ret;
}
@@ -623,7 +594,7 @@ static int cm_check_thermal_status(struct charger_manager
*cm)
* occur hazadous result. We have to handle it
* depending on battery type.
*/
- dev_err(cm->dev, "Failed to get battery temperature\n");
+ dev_dbg(cm->dev, "Failed to get battery temperature\n");
return 0;
}
@@ -1007,12 +978,11 @@ static enum power_supply_property
default_charger_props[] = {
POWER_SUPPLY_PROP_CAPACITY,
POWER_SUPPLY_PROP_ONLINE,
POWER_SUPPLY_PROP_CHARGE_FULL,
+ POWER_SUPPLY_PROP_TEMP,
/*
* Optional properties are:
* POWER_SUPPLY_PROP_CHARGE_NOW,
* POWER_SUPPLY_PROP_CURRENT_NOW,
-* POWER_SUPPLY_PROP_TEMP, and
-* POWER_SUPPLY_PROP_TEMP_AMBIENT,
*/
};
@@ -1417,49 +1387,6 @@ err:
return ret;
}
-static int cm_init_thermal_data(struct charger_manager *cm,
- struct power_supply *fuel_gauge)
-{
- struct charger_desc *desc = cm->desc;
- union power_supply_propval val;
- int ret;
-
- /* Verify whether fuel gauge provides battery temperature */
- ret = fuel_gauge->get_property(fuel_gauge,
- POWER_SUPPLY_PROP_TEMP, );
-
- if (!ret) {
- cm->charger_psy.properties[cm->charger_psy.num_properties] =
- POWER_SUPPLY_PROP_TEMP;
- cm->charger_psy.num_properties++;
- cm->desc->measure_battery_temp = true;
- }
-#ifdef CONFIG_THERMAL
- if (ret && desc->thermal_zone) {
- cm->tzd_batt =
- thermal_zone_get_zone_by_name(desc->thermal_zone);
- if (IS_ERR(cm->tzd_batt))
- return PTR_ERR(cm->tzd_batt);
-
- /* Use external thermometer */
- cm->charger_psy.properties[cm->charger_psy.num_properties] =
-
[PATCH RESEND v2 06/10] power: charger-manager: Get external power souce information only from EXTCON.
When charger-manager checks whether external power source is available,
it gets information from charger IC driver. However, it's not correct source,
charger IC doesn't have responsibilty to give cable connection status.
The charger-manager already gets cable information from EXTCON susbsystem,
so it can re-use it.
Signed-off-by: Jonghwa Lee
---
drivers/power/charger-manager.c | 34 ++
1 file changed, 14 insertions(+), 20 deletions(-)
diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index bb44588..172dfe5 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -115,34 +115,28 @@ static bool is_batt_present(struct charger_manager *cm)
* is_ext_pwr_online - See if an external power source is attached to charge
* @cm: the Charger Manager representing the battery.
*
- * Returns true if at least one of the chargers of the battery has an external
- * power source attached to charge the battery regardless of whether it is
- * actually charging or not.
+ * Returns true if there is external power source.
+ * Cable connection information is only obtained by EXTCON class notification.
*/
static bool is_ext_pwr_online(struct charger_manager *cm)
{
- union power_supply_propval val;
- struct power_supply *psy;
- bool online = false;
- int i, ret;
- /* If at least one of them has one, it's yes. */
- for (i = 0; cm->desc->psy_charger_stat[i]; i++) {
- psy = power_supply_get_by_name(cm->desc->psy_charger_stat[i]);
- if (!psy) {
- dev_err(cm->dev, "Cannot find power supply \"%s\"\n",
- cm->desc->psy_charger_stat[i]);
- continue;
- }
+ struct charger_desc *desc = cm->desc;
+ struct charger_regulator *regulators = desc->charger_regulators;
+ struct charger_cable *cables;
+ int i, j, num_cables;
- ret = psy->get_property(psy, POWER_SUPPLY_PROP_ONLINE, );
- if (ret == 0 && val.intval) {
- online = true;
- break;
+ /* If at least one of them has one, it's yes. */
+ for (i = 0; i < desc->num_charger_regulators; i++) {
+ cables = regulators[i].cables;
+ num_cables = regulators[i].num_cables;
+ for (j = 0; j < num_cables; j++) {
+ if (cables[j].attached)
+ return true;
}
}
- return online;
+ return false;
}
/**
--
1.7.9.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 RESEND V2 0/10] Improve charger manager driver for optimized operation.
After charger manager's initially introduced, it has kept its codes without any big change. However, the charger manager working operation isn't optimized and it also has unused codes and non-generic interface. This series tries to make charger manager more generic and maintainable with some fixes. [Changes in V2] - Rebase patch series on latest of battery-2.6.git. - Seperate 'power: charger-manager: Rearrange data and monitor ~' patch into several patches depends on its purpose. - Add 2 patches related with polling mode. Jonghwa Lee (10): power: charger-manager: Use thermal subsystem interface only to get temperature. power: charger-manager: Use power_supply_changed() not private uevent. power: charger-manager: Remove deprecated function, cm_notify_event(). power: charger-manager: Fix to use CHARGE_NOW/FULL property correctly. power: charger-manager: Concentrate scattered power_supply_changed() calls. power: charger-manager: Get external power souce information only from EXTCON. power: charger-manager: Make chraging decision focusing on battery status. power: charger-manager: Not to start charging directly in cable nofitication. power: charger-manager: Support different polling mode for sleep state. power: charger-manager: Support to change polling rate in runtime. .../bindings/power_supply/charger-manager.txt |1 - drivers/power/Kconfig |1 + drivers/power/charger-manager.c| 758 ++-- include/linux/power/charger-manager.h | 34 +- 4 files changed, 219 insertions(+), 575 deletions(-) -- 1.7.9.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 RESEND v2 04/10] power: charger-manager: Fix to use CHARGE_NOW/FULL property correctly.
The POWER_SUPPLY_CHARGE_NOW/FULL property reflects battery's charges
in uAh unit, but charger-manager has been used it wrongly. This patch
makes it to use those propeties correctly and change to be optional.
Signed-off-by: Jonghwa Lee
---
drivers/power/charger-manager.c | 85 +--
1 file changed, 28 insertions(+), 57 deletions(-)
diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index 64fdaaf..687f109 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -796,35 +796,13 @@ static int charger_get_property(struct power_supply *psy,
val->intval = 0;
break;
case POWER_SUPPLY_PROP_CHARGE_FULL:
- if (is_full_charged(cm))
- val->intval = 1;
- else
- val->intval = 0;
- ret = 0;
- break;
case POWER_SUPPLY_PROP_CHARGE_NOW:
- if (is_charging(cm)) {
- fuel_gauge = power_supply_get_by_name(
- cm->desc->psy_fuel_gauge);
- if (!fuel_gauge) {
- ret = -ENODEV;
- break;
- }
-
- ret = fuel_gauge->get_property(fuel_gauge,
- POWER_SUPPLY_PROP_CHARGE_NOW,
- val);
- if (ret) {
- val->intval = 1;
- ret = 0;
- } else {
- /* If CHARGE_NOW is supplied, use it */
- val->intval = (val->intval > 0) ?
- val->intval : 1;
- }
- } else {
- val->intval = 0;
+ fuel_gauge = power_supply_get_by_name(cm->desc->psy_fuel_gauge);
+ if (!fuel_gauge) {
+ ret = -ENODEV;
+ break;
}
+ ret = fuel_gauge->get_property(fuel_gauge, psp, val);
break;
default:
return -EINVAL;
@@ -832,8 +810,7 @@ static int charger_get_property(struct power_supply *psy,
return ret;
}
-#define NUM_CHARGER_PSY_OPTIONAL (4)
-static enum power_supply_property default_charger_props[] = {
+static enum power_supply_property cm_default_props[] = {
/* Guaranteed to provide */
POWER_SUPPLY_PROP_STATUS,
POWER_SUPPLY_PROP_HEALTH,
@@ -841,20 +818,21 @@ static enum power_supply_property default_charger_props[]
= {
POWER_SUPPLY_PROP_VOLTAGE_NOW,
POWER_SUPPLY_PROP_CAPACITY,
POWER_SUPPLY_PROP_ONLINE,
- POWER_SUPPLY_PROP_CHARGE_FULL,
POWER_SUPPLY_PROP_TEMP,
- /*
-* Optional properties are:
-* POWER_SUPPLY_PROP_CHARGE_NOW,
-* POWER_SUPPLY_PROP_CURRENT_NOW,
-*/
};
+static enum power_supply_property cm_optional_props[] = {
+ POWER_SUPPLY_PROP_CHARGE_FULL,
+ POWER_SUPPLY_PROP_CHARGE_NOW,
+ POWER_SUPPLY_PROP_CURRENT_NOW,
+};
+
+#define CM_NUM_OF_PROPS\
+ (ARRAY_SIZE(cm_default_props) + ARRAY_SIZE(cm_optional_props))
+
static struct power_supply psy_default = {
.name = "battery",
.type = POWER_SUPPLY_TYPE_BATTERY,
- .properties = default_charger_props,
- .num_properties = ARRAY_SIZE(default_charger_props),
.get_property = charger_get_property,
.no_thermal = true,
};
@@ -1484,29 +1462,22 @@ static int charger_manager_probe(struct platform_device
*pdev)
/* Allocate for psy properties because they may vary */
cm->charger_psy.properties = devm_kzalloc(>dev,
sizeof(enum power_supply_property)
- * (ARRAY_SIZE(default_charger_props) +
- NUM_CHARGER_PSY_OPTIONAL), GFP_KERNEL);
+ * CM_NUM_OF_PROPS, GFP_KERNEL);
if (!cm->charger_psy.properties)
return -ENOMEM;
- memcpy(cm->charger_psy.properties, default_charger_props,
- sizeof(enum power_supply_property) *
- ARRAY_SIZE(default_charger_props));
- cm->charger_psy.num_properties = psy_default.num_properties;
-
- /* Find which optional psy-properties are available */
- if (!fuel_gauge->get_property(fuel_gauge,
- POWER_SUPPLY_PROP_CHARGE_NOW, )) {
- cm->charger_psy.properties[cm->charger_psy.num_properties] =
- POWER_SUPPLY_PROP_CHARGE_NOW;
- cm->charger_psy.num_properties++;
- }
- if (!fuel_gauge->get_property(fuel_gauge,
- POWER_SUPPLY_PROP_CURRENT_NOW,
-
[PATCH RESEND v2 08/10] power: charger-manager: Not to start charging directly in cable nofitication.
This patch prevents direct charging control in cable notification.
It sets only input current limit according to cable type and yields charging
control to be done by cm_monitor() where charging management proceeds.
It may loose few ms to enable charging compared to before, even though it's
more important that charging is enabled always in safe context.
Signed-off-by: Jonghwa Lee
---
drivers/power/charger-manager.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index 065b92a..1ccb9be 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -849,7 +849,8 @@ static void charger_extcon_work(struct work_struct *work)
cable->min_uA, cable->max_uA);
}
- try_charger_enable(cable->cm, cable->attached);
+ cancel_delayed_work(_monitor_work);
+ queue_delayed_work(cm_wq, _monitor_work, 0);
}
/**
@@ -873,15 +874,6 @@ static int charger_extcon_notifier(struct notifier_block
*self,
cable->attached = event;
/*
-* Setup monitoring to check battery state
-* when charger cable is attached.
-*/
- if (cable->attached && is_polling_required(cable->cm)) {
- cancel_work_sync(_polling);
- schedule_work(_polling);
- }
-
- /*
* Setup work for controlling charger(regulator)
* according to charger cable.
*/
--
1.7.9.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 RESEND v2 05/10] power: charger-manager: Concentrate scattered power_supply_changed() calls.
Current charger-manager calls power_suuply_changed() whenever charging
status is changed. This patch removes seperated power_supply_changed()
use and let it be called at end of try_charger_enable() function which
is called to set charging/discharging.
Signed-off-by: Jonghwa Lee
---
drivers/power/charger-manager.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index 687f109..bb44588 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -382,8 +382,10 @@ static int try_charger_enable(struct charger_manager *cm,
bool enable)
}
}
- if (!err)
+ if (!err) {
cm->charger_enabled = enable;
+ power_supply_changed(>charger_psy);
+ }
return err;
}
@@ -436,10 +438,8 @@ static void fullbatt_vchk(struct charger_manager *cm)
dev_info(cm->dev, "VBATT dropped %duV after full-batt\n", diff);
- if (diff > desc->fullbatt_vchkdrop_uV) {
+ if (diff > desc->fullbatt_vchkdrop_uV)
try_charger_restart(cm);
- power_supply_changed(>charger_psy);
- }
}
/**
@@ -469,7 +469,6 @@ static int check_charging_duration(struct charger_manager
*cm)
if (duration > desc->charging_max_duration_ms) {
dev_info(cm->dev, "Charging duration exceed %ums\n",
desc->charging_max_duration_ms);
- power_supply_changed(>charger_psy);
try_charger_enable(cm, false);
ret = true;
}
@@ -480,7 +479,6 @@ static int check_charging_duration(struct charger_manager
*cm)
is_ext_pwr_online(cm)) {
dev_info(cm->dev, "Discharging duration exceed %ums\n",
desc->discharging_max_duration_ms);
- power_supply_changed(>charger_psy);
try_charger_enable(cm, true);
ret = true;
}
@@ -561,8 +559,7 @@ static bool _cm_monitor(struct charger_manager *cm)
*/
if (temp_alrt) {
cm->emergency_stop = temp_alrt;
- if (!try_charger_enable(cm, false))
- power_supply_changed(>charger_psy);
+ try_charger_enable(cm, false);
/*
* Check whole charging duration and discharing duration
@@ -587,16 +584,13 @@ static bool _cm_monitor(struct charger_manager *cm)
} else if (!cm->emergency_stop && is_full_charged(cm) &&
cm->charger_enabled) {
dev_info(cm->dev, "EVENT_HANDLE: Battery Fully Charged\n");
- power_supply_changed(>charger_psy);
-
try_charger_enable(cm, false);
fullbatt_vchk(cm);
} else {
cm->emergency_stop = 0;
if (is_ext_pwr_online(cm)) {
- if (!try_charger_enable(cm, true))
- power_supply_changed(>charger_psy);
+ try_charger_enable(cm, true);
}
}
--
1.7.9.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 RESEND v2 10/10] power: charger-manager: Support to change polling rate in runtime.
Add 'polling_ms' sysfs node to change charger-manager's monitoring rate
in runtime. It can set only bigger than 2 jiffies (for 200 HZ system it
is 10 msecs.) as it's allowed for minimum poling rate in previous.
It resets poller and re-configure polling rate based on new input if next
polling time is far enough. Otherwise, it just waits expiration of timer
and new polling rate will affects the next scheduling.
Signed-off-by: Jonghwa Lee
---
drivers/power/charger-manager.c | 62 +++
1 file changed, 62 insertions(+)
diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index 0a0834f..7a007f4 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -1054,6 +1054,63 @@ static ssize_t charger_externally_control_store(struct
device *dev,
return count;
}
+static ssize_t show_polling_ms(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct charger_manager *cm;
+ ssize_t len;
+
+ list_for_each_entry(cm, _list, entry)
+ if (cm->charger_psy.dev == dev)
+ break;
+
+ if (cm->charger_psy.dev != dev)
+ return -EINVAL;
+
+ len = sprintf(buf, "%d\n", cm->desc->polling_interval_ms);
+
+ return len;
+}
+
+static ssize_t store_polling_ms(struct device *dev,
+ struct device_attribute *attr, const char *buf,
+ size_t count)
+{
+ struct charger_manager *cm;
+ int polling_ms;
+ int ret;
+
+ ret = sscanf(buf, "%d", _ms);
+ if (ret < 0 )
+ return -EINVAL;
+
+ if (polling_ms < CM_JIFFIES_SMALL * MSEC_PER_SEC / HZ)
+ return -EINVAL;
+
+ list_for_each_entry(cm, _list, entry)
+ if (cm->charger_psy.dev == dev)
+ break;
+
+ if (cm->charger_psy.dev != dev)
+ return -ENODEV;
+
+ cm->desc->polling_interval_ms = polling_ms;
+
+ pr_info("Polling interval's changed to %u ms.\n",
+ cm->desc->polling_interval_ms);
+
+ if (next_polling - jiffies >
+ msecs_to_jiffies(cm->desc->polling_interval_ms)) {
+ pr_info("Reset poller now... \n");
+ cancel_delayed_work(_monitor_work);
+ schedule_work(_polling);
+ }
+
+ return count;
+}
+
+static DEVICE_ATTR(polling_ms, 0644, show_polling_ms, store_polling_ms);
+
/**
* charger_manager_register_sysfs - Register sysfs entry for each charger
* @cm: the Charger Manager representing the battery.
@@ -1077,6 +1134,11 @@ static int charger_manager_register_sysfs(struct
charger_manager *cm)
int ret = 0;
int i;
+ /* Create polling_ms sysfs node */
+ ret = device_create_file(cm->charger_psy.dev, _attr_polling_ms);
+ if (ret)
+ pr_err("Failed to create poling_ms sysfs node (%d)\n", ret);
+
/* Create sysfs entry to control charger(regulator) */
for (i = 0; i < desc->num_charger_regulators; i++) {
charger = >charger_regulators[i];
--
1.7.9.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 RESEND v2 03/10] power: charger-manager: Remove deprecated function, cm_notify_event().
cm_notify_event() is introduced to get event associated with battery status
externally, but no one had been used. Moreover it makes charger manager
driver more complicated. This patch tries to drop the function and all data
related to simplify the driver.
Signed-off-by: Jonghwa Lee
---
.../bindings/power_supply/charger-manager.txt |1 -
drivers/power/charger-manager.c| 196 +---
include/linux/power/charger-manager.h | 19 +-
3 files changed, 8 insertions(+), 208 deletions(-)
diff --git a/Documentation/devicetree/bindings/power_supply/charger-manager.txt
b/Documentation/devicetree/bindings/power_supply/charger-manager.txt
index 2b33750..767aaa5 100644
--- a/Documentation/devicetree/bindings/power_supply/charger-manager.txt
+++ b/Documentation/devicetree/bindings/power_supply/charger-manager.txt
@@ -39,7 +39,6 @@ Example :
cm-poll-mode = <1>;
cm-poll-interval = <3>;
- cm-fullbatt-vchkdrop-ms = <3>;
cm-fullbatt-vchkdrop-volt = <15>;
cm-fullbatt-soc = <100>;
diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index 33a1a4d..64fdaaf 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -410,25 +410,18 @@ static int try_charger_restart(struct charger_manager *cm)
/**
* fullbatt_vchk - Check voltage drop some times after "FULL" event.
- * @work: the work_struct appointing the function
*
- * If a user has designated "fullbatt_vchkdrop_ms/uV" values with
+ * If a user has designated "fullbatt_vchkdrop_uV" values with
* charger_desc, Charger Manager checks voltage drop after the battery
* "FULL" event. It checks whether the voltage has dropped more than
* fullbatt_vchkdrop_uV by calling this function after fullbatt_vchkrop_ms.
*/
-static void fullbatt_vchk(struct work_struct *work)
+static void fullbatt_vchk(struct charger_manager *cm)
{
- struct delayed_work *dwork = to_delayed_work(work);
- struct charger_manager *cm = container_of(dwork,
- struct charger_manager, fullbatt_vchk_work);
struct charger_desc *desc = cm->desc;
int batt_uV, err, diff;
- /* remove the appointment for fullbatt_vchk */
- cm->fullbatt_vchk_jiffies_at = 0;
-
- if (!desc->fullbatt_vchkdrop_uV || !desc->fullbatt_vchkdrop_ms)
+ if (!desc->fullbatt_vchkdrop_uV)
return;
err = get_batt_uV(cm, _uV);
@@ -585,7 +578,7 @@ static bool _cm_monitor(struct charger_manager *cm)
*/
} else if (!cm->emergency_stop && is_ext_pwr_online(cm) &&
!cm->charger_enabled) {
- fullbatt_vchk(>fullbatt_vchk_work.work);
+ fullbatt_vchk(cm);
/*
* Check whether fully charged state to protect overcharge
@@ -598,7 +591,7 @@ static bool _cm_monitor(struct charger_manager *cm)
try_charger_enable(cm, false);
- fullbatt_vchk(>fullbatt_vchk_work.work);
+ fullbatt_vchk(cm);
} else {
cm->emergency_stop = 0;
if (is_ext_pwr_online(cm)) {
@@ -700,66 +693,6 @@ static void cm_monitor_poller(struct work_struct *work)
schedule_work(_polling);
}
-/**
- * fullbatt_handler - Event handler for CM_EVENT_BATT_FULL
- * @cm: the Charger Manager representing the battery.
- */
-static void fullbatt_handler(struct charger_manager *cm)
-{
- struct charger_desc *desc = cm->desc;
-
- if (!desc->fullbatt_vchkdrop_uV || !desc->fullbatt_vchkdrop_ms)
- goto out;
-
- if (cm_suspended)
- device_set_wakeup_capable(cm->dev, true);
-
- mod_delayed_work(cm_wq, >fullbatt_vchk_work,
-msecs_to_jiffies(desc->fullbatt_vchkdrop_ms));
- cm->fullbatt_vchk_jiffies_at = jiffies + msecs_to_jiffies(
- desc->fullbatt_vchkdrop_ms);
-
- if (cm->fullbatt_vchk_jiffies_at == 0)
- cm->fullbatt_vchk_jiffies_at = 1;
-
-out:
- dev_info(cm->dev, "EVENT_HANDLE: Battery Fully Charged\n");
- power_supply_changed(>charger_psy);
-}
-
-/**
- * battout_handler - Event handler for CM_EVENT_BATT_OUT
- * @cm: the Charger Manager representing the battery.
- */
-static void battout_handler(struct charger_manager *cm)
-{
- if (cm_suspended)
- device_set_wakeup_capable(cm->dev, true);
-
- if (!is_batt_present(cm)) {
- dev_emerg(cm->dev, "Battery Pulled Out!\n");
- power_supply_changed(>charger_psy);
- } else {
- power_supply_changed(>charger_psy);
- }
-}
-
-/**
- * misc_event_handler - Handler for other evnets
- * @cm: the Charger Manager representing the battery.
- * @type: the Charger Manager representing the battery.
- */
-static void misc_event_handler(struct charger_manager *cm,
-
[PATCH RESEND v2 09/10] power: charger-manager: Support different polling mode for sleep state.
Add additional polling mode for sleep state to define different mode with
normal state. With this change, charger-manager can work differently in
normal state or sleep state. e.g, polling aways for normal and polling
only when charing for sleep. If there is no defined polling mode for
sleep state it just follows the normal state's.
In addition to, polling rate is still same in sleep.
Signed-off-by: Jonghwa Lee
---
drivers/power/charger-manager.c | 20 +---
include/linux/power/charger-manager.h |9 ++---
2 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index 1ccb9be..0a0834f 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -291,7 +291,15 @@ static bool is_full_charged(struct charger_manager *cm)
*/
static bool is_polling_required(struct charger_manager *cm)
{
- switch (cm->desc->polling_mode) {
+ enum polling_modes polling_mode;
+
+ if (cm_suspended
+ && cm->desc->poll_mode_sleep >= 0)
+ polling_mode = cm->desc->poll_mode_sleep;
+ else
+ polling_mode = cm->desc->poll_mode_normal;
+
+ switch (polling_mode) {
case CM_POLL_DISABLE:
return false;
case CM_POLL_ALWAYS:
@@ -302,7 +310,7 @@ static bool is_polling_required(struct charger_manager *cm)
return is_charging(cm);
default:
dev_warn(cm->dev, "Incorrect polling_mode (%d)\n",
-cm->desc->polling_mode);
+polling_mode);
}
return false;
@@ -1158,7 +1166,13 @@ static struct charger_desc *of_cm_parse_desc(struct
device *dev)
of_property_read_string(np, "cm-name", >psy_name);
of_property_read_u32(np, "cm-poll-mode", _mode);
- desc->polling_mode = poll_mode;
+ desc->poll_mode_normal = poll_mode;
+
+ /* Polling mode in sleep state */
+ if (!of_property_read_u32(np, "cm-poll-mode-sleep", _mode))
+ desc->poll_mode_sleep = poll_mode;
+ else
+ desc->poll_mode_sleep = -EINVAL;
of_property_read_u32(np, "cm-poll-interval",
>polling_interval_ms);
diff --git a/include/linux/power/charger-manager.h
b/include/linux/power/charger-manager.h
index 37fb181..a30a0b6 100644
--- a/include/linux/power/charger-manager.h
+++ b/include/linux/power/charger-manager.h
@@ -131,8 +131,10 @@ struct charger_regulator {
/**
* struct charger_desc
* @psy_name: the name of power-supply-class for charger manager
- * @polling_mode:
- * Determine which polling mode will be used
+ * @poll_mode_normal:
+ * Determine which polling mode will be used in normal state.
+ * @poll_mode_sleep:
+ * Determine which polling mode will be used in sleep state.
* @fullbatt_vchkdrop_uV:
* Check voltage drop after the battery is fully charged.
* If it has dropped more than fullbatt_vchkdrop_uV
@@ -170,7 +172,8 @@ struct charger_regulator {
struct charger_desc {
const char *psy_name;
- enum polling_modes polling_mode;
+ enum polling_modes poll_mode_normal;
+ enum polling_modes poll_mode_sleep;
unsigned int polling_interval_ms;
unsigned int fullbatt_vchkdrop_uV;
--
1.7.9.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] i2c: designware: use {readl|writel}_relaxed instead of readl/writel
Dear all,
Is there any issue I need to resolve so that the patch can be merged?
Thanks in advance,
Jisheng
On Wed, 10 Dec 2014 22:26:41 -0800
Jisheng Zhang wrote:
> readl/writel is too expensive especially on Cortex A9 w/ outer L2 cache.
> This introduces i2c read/write errors on Marvell BG2/BG2Q SoCs when there
> are heavy L2 cache maintenance operations at the same time.
>
> The driver does not perform DMA, so it's safe to use the relaxed version.
> From another side, the relaxed io accessor macros are available on all
> architectures now, so we can use the relaxed versions instead.
>
> Signed-off-by: Jisheng Zhang
> ---
> drivers/i2c/busses/i2c-designware-core.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-designware-core.c
> b/drivers/i2c/busses/i2c-designware-core.c index 23628b7..e279948 100644
> --- a/drivers/i2c/busses/i2c-designware-core.c
> +++ b/drivers/i2c/busses/i2c-designware-core.c
> @@ -170,10 +170,10 @@ u32 dw_readl(struct dw_i2c_dev *dev, int offset)
> u32 value;
>
> if (dev->accessor_flags & ACCESS_16BIT)
> - value = readw(dev->base + offset) |
> - (readw(dev->base + offset + 2) << 16);
> + value = readw_relaxed(dev->base + offset) |
> + (readw_relaxed(dev->base + offset + 2) << 16);
> else
> - value = readl(dev->base + offset);
> + value = readl_relaxed(dev->base + offset);
>
> if (dev->accessor_flags & ACCESS_SWAP)
> return swab32(value);
> @@ -187,10 +187,10 @@ void dw_writel(struct dw_i2c_dev *dev, u32 b, int
> offset) b = swab32(b);
>
> if (dev->accessor_flags & ACCESS_16BIT) {
> - writew((u16)b, dev->base + offset);
> - writew((u16)(b >> 16), dev->base + offset + 2);
> + writew_relaxed((u16)b, dev->base + offset);
> + writew_relaxed((u16)(b >> 16), dev->base + offset + 2);
> } else {
> - writel(b, dev->base + offset);
> + writel_relaxed(b, dev->base + offset);
> }
> }
>
--
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] kdump, vmcoreinfo: report actual value of phys_base
On 11/13/14 at 11:30am, HATAYAMA Daisuke wrote:
> Currently, VMCOREINFO note information reports the virtual address of
> phys_base that is assigned to symbol phys_base. But this doesn't make
> sense because to refer to phys_base, it's necessary to get the value
> of phys_base itself we are now about to refer to.
>
> Userland tools related to kdump such as makedumpfile and crash utility
> so far have made some efforts to calculate phys_base on crash dump
> formats generated by mechanisms running outside Linux kernel, such as
> virtual machine hypervisor such as qemu dump, which ordinary users use
> via virsh dump, or ones implemented on vendor specific firmware.
>
> That is, find a kernel data whose virtual and physical addresses are
> available via its note information and calculate phys_base from
> it. However, such data structure is not the one prepared for phys_base
> purpose. There's no guarantee that other crash dump mechanisms include
> such information that can be used to calculate phys_base similarly.
>
> To get VMCOREINFO in vmcore, it's easy to use strings and grep
> commands like this; VMCOREINFO consists of simple string:
>
> $ strings vmcore-3.10.0-121.el7.x86_64 | grep -E ".*VMCOREINFO.*" -A 100
> VMCOREINFO
> OSRELEASE=3.10.0-121.el7.x86_64
> PAGESIZE=4096
> ...
>
> This is also useful to get value of phys_base in kdump 2nd kernel
> contained in vmcore using the above-mentioned external crash dump
> mechanism; kdump 2nd kernel is an inherently relocated kernel.
>
> This commit doesn't remove VMCOREINFO_SYMBOL(phys_base) line because
> makedumpfile refers to it and if removing it, old versions
> makedumpfile doesn't work well.
>
> ChangeLog:
> v2:
> - Introduce VMCOREINFO_PHYS_BASE().
> - Correct patch description: this work is primarily for mechanisms
> running outside (kdump 1st) Linux kernel.
>
> Signed-off-by: HATAYAMA Daisuke
> ---
> arch/x86/kernel/machine_kexec_64.c | 1 +
> include/linux/kexec.h | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/arch/x86/kernel/machine_kexec_64.c
> b/arch/x86/kernel/machine_kexec_64.c
> index 4859810..47cc835 100644
> --- a/arch/x86/kernel/machine_kexec_64.c
> +++ b/arch/x86/kernel/machine_kexec_64.c
> @@ -334,6 +334,7 @@ void arch_crash_save_vmcoreinfo(void)
> #endif
> vmcoreinfo_append_str("KERNELOFFSET=%lx\n",
> (unsigned long)&_text - __START_KERNEL);
> + VMCOREINFO_PHYS_BASE(phys_base);
> }
>
> /* arch-dependent functionality related to kexec file-based syscall */
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 9d957b7..bee3c5b 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -258,6 +258,8 @@ unsigned long paddr_vmcoreinfo_note(void);
> vmcoreinfo_append_str("NUMBER(%s)=%ld\n", #name, (long)name)
> #define VMCOREINFO_CONFIG(name) \
> vmcoreinfo_append_str("CONFIG_%s=y\n", #name)
> +#define VMCOREINFO_PHYS_BASE(value) \
> + vmcoreinfo_append_str("PHYS_BASE=%lx\n", (unsigned long)value)
I don't like the idea that add a new MACRO for a specific case. I prefer
it to be a generic MACRO which can be used by later adding if they want
to add a unsigned long value.
>
> extern struct kimage *kexec_image;
> extern struct kimage *kexec_crash_image;
> --
> 1.9.3
>
>
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
--
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: [f2fs-dev] [PATCH v3] f2fs: use ra_meta_pages to simplify readahead code in restore_node_summary
Hi Jaegeuk,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Friday, December 19, 2014 3:13 AM
> To: Chao Yu
> Cc: Changman Lee; linux-f2fs-de...@lists.sourceforge.net;
> linux-fsde...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [f2fs-dev] [PATCH v3] f2fs: use ra_meta_pages to simplify
> readahead code in
> restore_node_summary
>
> Hi Chao,
>
> On Thu, Dec 18, 2014 at 06:29:05PM +0800, Chao Yu wrote:
> > Use more common function ra_meta_pages() with META_POR to readahead node
> > blocks
> > in restore_node_summary() instead of ra_sum_pages(), hence we can simplify
> > the
> > readahead code there, and also we can remove unused function ra_sum_pages().
> >
> > changes from v2:
> > o use invalidate_mapping_pages as before suggested by Changman Lee.
> > changes from v1:
> > o fix one bug when using truncate_inode_pages_range which is pointed out by
> >Jaegeuk Kim.
> >
> > Reviewed-by: Changman Lee
> > Signed-off-by: Chao Yu
> > ---
> > fs/f2fs/node.c | 63
> > +++---
> > 1 file changed, 12 insertions(+), 51 deletions(-)
> >
> > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> > index 5aa54a0..17bf239 100644
> > --- a/fs/f2fs/node.c
> > +++ b/fs/f2fs/node.c
> > @@ -1726,80 +1726,41 @@ int recover_inode_page(struct f2fs_sb_info *sbi,
> > struct page *page)
> > return 0;
> > }
> >
> > -/*
> > - * ra_sum_pages() merge contiguous pages into one bio and submit.
> > - * these pre-read pages are allocated in bd_inode's mapping tree.
> > - */
> > -static int ra_sum_pages(struct f2fs_sb_info *sbi, struct page **pages,
> > - int start, int nrpages)
> > -{
> > - struct inode *inode = sbi->sb->s_bdev->bd_inode;
> > - struct address_space *mapping = inode->i_mapping;
> > - int i, page_idx = start;
> > - struct f2fs_io_info fio = {
> > - .type = META,
> > - .rw = READ_SYNC | REQ_META | REQ_PRIO
> > - };
> > -
> > - for (i = 0; page_idx < start + nrpages; page_idx++, i++) {
> > - /* alloc page in bd_inode for reading node summary info */
> > - pages[i] = grab_cache_page(mapping, page_idx);
> > - if (!pages[i])
> > - break;
> > - f2fs_submit_page_mbio(sbi, pages[i], page_idx, );
> > - }
> > -
> > - f2fs_submit_merged_bio(sbi, META, READ);
> > - return i;
> > -}
> > -
> > int restore_node_summary(struct f2fs_sb_info *sbi,
> > unsigned int segno, struct f2fs_summary_block *sum)
> > {
> > struct f2fs_node *rn;
> > struct f2fs_summary *sum_entry;
> > - struct inode *inode = sbi->sb->s_bdev->bd_inode;
> > block_t addr;
> > int bio_blocks = MAX_BIO_BLOCKS(sbi);
> > - struct page *pages[bio_blocks];
> > - int i, idx, last_offset, nrpages, err = 0;
> > + int i, idx, last_offset, nrpages;
> >
> > /* scan the node segment */
> > last_offset = sbi->blocks_per_seg;
> > addr = START_BLOCK(sbi, segno);
> > sum_entry = >entries[0];
> >
> > - for (i = 0; !err && i < last_offset; i += nrpages, addr += nrpages) {
> > + for (i = 0; i < last_offset; i += nrpages, addr += nrpages) {
> > nrpages = min(last_offset - i, bio_blocks);
> >
> > /* readahead node pages */
> > - nrpages = ra_sum_pages(sbi, pages, addr, nrpages);
> > - if (!nrpages)
> > - return -ENOMEM;
> > + ra_meta_pages(sbi, addr, nrpages, META_POR);
> >
> > - for (idx = 0; idx < nrpages; idx++) {
> > - if (err)
> > - goto skip;
> > + for (idx = addr; idx < addr + nrpages; idx++) {
> > + struct page *page = get_meta_page(sbi, idx);
> >
> > - lock_page(pages[idx]);
> > - if (unlikely(!PageUptodate(pages[idx]))) {
> > - err = -EIO;
> > - } else {
> > - rn = F2FS_NODE(pages[idx]);
> > - sum_entry->nid = rn->footer.nid;
> > - sum_entry->version = 0;
> > - sum_entry->ofs_in_node = 0;
> > - sum_entry++;
> > - }
> > - unlock_page(pages[idx]);
> > -skip:
> > - page_cache_release(pages[idx]);
> > + rn = F2FS_NODE(page);
> > + sum_entry->nid = rn->footer.nid;
> > + sum_entry->version = 0;
> > + sum_entry->ofs_in_node = 0;
> > + sum_entry++;
> > + f2fs_put_page(page, 1);
> > }
> >
> > invalidate_mapping_pages(inode->i_mapping, addr,
> > addr + nrpages);
>
> This causes a build error.
Sorry, out of my mind at that time.
> Let's use META_MAPPING() here.
> If you don't mind, I'll change this and
RE: [PATCH] checkpatch: Fix MAINTAINERS search pattern
> On Thu, 2014-12-18 at 12:12 -0800, Derek Chickles wrote: > > This fixes the check that was supposed to prevent the MAINTAINERS > > warning from appearing when you run checkpatch.pl on a patch that > > includes new files/directories and an updated MAINTAINERS file. > > This suggested patch doesn't work. > > $realfile isn't set until the file shows up > in the patch itself. > > The current test looks at the changelog > before the files are modified and is correct. > Thanks, you're right. My mistake was trying to run checkpatch.pl on a diff. My patch works on diffs while the original code does not. This is by chance really because MAINTAINERS is early in the patch. Using format-patch on something that is committed is clearly the correct solution. -- 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] lib/genalloc.c: fix the end addr check in addr_in_gen_pool()
Since chunk->end_addr is (chunk->start_addr + size - 1),
the end address to compare should be (start + size - 1).
Signed-off-by: Toshi Kikuchi
---
lib/genalloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/genalloc.c b/lib/genalloc.c
index 2e65d20..42a95e9 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -415,7 +415,7 @@ bool addr_in_gen_pool(struct gen_pool *pool, unsigned long
start,
size_t size)
{
bool found = false;
- unsigned long end = start + size;
+ unsigned long end = start + size - 1;
struct gen_pool_chunk *chunk;
rcu_read_lock();
--
2.2.0.rc0.207.ga3a616c
--
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: [v3 16/26] KVM: Make struct kvm_irq_routing_table accessible
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Paolo Bonzini
> Sent: Thursday, December 18, 2014 12:18 AM
> To: linux-kernel@vger.kernel.org
> Cc: io...@lists.linux-foundation.org; k...@vger.kernel.org;
> linux-kernel@vger.kernel.org; k...@vger.kernel.org
> Subject: Re: [v3 16/26] KVM: Make struct kvm_irq_routing_table accessible
>
>
>
> On 12/12/2014 16:14, Feng Wu wrote:
> > Move struct kvm_irq_routing_table from irqchip.c to kvm_host.h,
> > so we can use it outside of irqchip.c.
> >
> > Signed-off-by: Feng Wu
> > ---
> > include/linux/kvm_host.h | 19 +++
> > virt/kvm/irqchip.c | 11 ---
> > 2 files changed, 19 insertions(+), 11 deletions(-)
> >
> > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> > index 0b9659d..cfa85ac 100644
> > --- a/include/linux/kvm_host.h
> > +++ b/include/linux/kvm_host.h
> > @@ -335,6 +335,25 @@ struct kvm_kernel_irq_routing_entry {
> > struct hlist_node link;
> > };
> >
> > +#ifdef CONFIG_HAVE_KVM_IRQ_ROUTING
> > +
> > +struct kvm_irq_routing_table {
> > + int chip[KVM_NR_IRQCHIPS][KVM_IRQCHIP_NUM_PINS];
> > + struct kvm_kernel_irq_routing_entry *rt_entries;
> > + u32 nr_rt_entries;
> > + /*
> > +* Array indexed by gsi. Each entry contains list of irq chips
> > +* the gsi is connected to.
> > +*/
> > + struct hlist_head map[0];
> > +};
> > +
> > +#else
> > +
> > +struct kvm_irq_routing_table {};
>
> If possible, just make this "struct kvm_irq_routing_table;" and pull
> this line to include/linux/kvm_types.h.
>
> Paolo
Do you mean move the definition of struct kvm_irq_routing_table
to include/linux/kvm_types.h and add a declaration here?
Thanks,
Feng
>
> > +
> > +#endif
> > +
> > #ifndef KVM_PRIVATE_MEM_SLOTS
> > #define KVM_PRIVATE_MEM_SLOTS 0
> > #endif
> > diff --git a/virt/kvm/irqchip.c b/virt/kvm/irqchip.c
> > index 7f256f3..cdf29a6 100644
> > --- a/virt/kvm/irqchip.c
> > +++ b/virt/kvm/irqchip.c
> > @@ -31,17 +31,6 @@
> > #include
> > #include "irq.h"
> >
> > -struct kvm_irq_routing_table {
> > - int chip[KVM_NR_IRQCHIPS][KVM_IRQCHIP_NUM_PINS];
> > - struct kvm_kernel_irq_routing_entry *rt_entries;
> > - u32 nr_rt_entries;
> > - /*
> > -* Array indexed by gsi. Each entry contains list of irq chips
> > -* the gsi is connected to.
> > -*/
> > - struct hlist_head map[0];
> > -};
> > -
> > int kvm_irq_map_gsi(struct kvm *kvm,
> > struct kvm_kernel_irq_routing_entry *entries, int gsi)
> > {
> >
>
> --
> 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/
--
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 RFC v2 06/14] ARM: dts: imx6qdl: Move existing MIPI DSI ports into a new 'ports' node
Hi Philipp, On 12/18/2014 06:33 PM, Philipp Zabel wrote: Am Donnerstag, den 18.12.2014, 15:11 +0800 schrieb Liu Ying: The MIPI DSI node contains some ports which represent possible DRM CRTCs it can connect with. Each port has a 'reg' property embedded. This property will be wrongly interpretted by the MIPI DSI bus driver, because the driver will take each subnode which contains a 'reg' property as a DSI peripheral device. This patch moves the existing MIPI DSI ports into a new 'ports' node so that the MIPI DSI bus driver may distinguish its DSI peripheral device(s) from the existing ports. Signed-off-by: Liu Ying Acked-by: Philipp Zabel Thanks. I'll add your ack for this one in the next version. Regards, Liu Ying regards Philipp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v2 05/14] ARM: imx6q: clk: Add the video_27m clock
Hi Philipp,
On 12/18/2014 06:31 PM, Philipp Zabel wrote:
Am Donnerstag, den 18.12.2014, 15:11 +0800 schrieb Liu Ying:
This patch supports the video_27m clock which is a fixed factor
clock of the pll3_pfd1_540m clock.
Signed-off-by: Liu Ying
---
v1->v2:
* None.
arch/arm/mach-imx/clk-imx6q.c | 1 +
include/dt-bindings/clock/imx6qdl-clock.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 4e79da7..9470df3 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -246,6 +246,7 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
clk[IMX6QDL_CLK_PLL3_60M] = imx_clk_fixed_factor("pll3_60m",
"pll3_usb_otg", 1, 8);
clk[IMX6QDL_CLK_TWD] = imx_clk_fixed_factor("twd", "arm",
1, 2);
clk[IMX6QDL_CLK_GPT_3M]= imx_clk_fixed_factor("gpt_3m","osc",
1, 8);
+ clk[IMX6QDL_CLK_VIDEO_27M] = imx_clk_fixed_factor("video_27m",
"pll3_pfd1_540m", 1, 20);
The HDMI TX isfr clock input is sourced from video_27m, too, according
to Table 33-1 "HDMI clocks".
I think the parent of clk[IMX6QDL_CLK_HDMI_ISFR] should be changed from
"pll3_pfd1_540m" to "video_27m", then.
I'll add a new patch in the next version to change the hdmi_isfr
clock's parent.
Thanks,
Liu Ying
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] Staging: wlan-ng: hfa384x_usb: fixed an 'else' statement coding style issue
Checkpatch was complaining about the else statement because the if statement
had a return '1' call. Taking a look at the function which this else statement
belongs, you can see that it has an switch case statement.
The main idea of the function is to return '1' if you get into any of the cases
(including the default case where the "problematic" if/else statement is
declared).
If any of the cases is not sufficient the function should return '0', so the
else statement that checkpath was complaining could be removed, and what was
done inside this else statement can be done outside the switch case statement
and then we return '0'.
This way we have a cleaner code and no checkpatch error complaints.
Signed-off-by: Eduardo Barretto
---
drivers/staging/wlan-ng/hfa384x_usb.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
b/drivers/staging/wlan-ng/hfa384x_usb.c
index 55d2f56..de33a07 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -4123,12 +4123,11 @@ static int hfa384x_isgood_pdrcode(u16 pdrcode)
pr_debug("Encountered unknown PDR#=0x%04x, assuming
it's ok.\n",
pdrcode);
return 1;
- } else {
- /* bad code */
- pr_debug("Encountered unknown PDR#=0x%04x, (>=0x1000),
assuming it's bad.\n",
-pdrcode);
- return 0;
}
+ break;
}
- return 0; /* avoid compiler warnings */
+ /* bad code */
+ pr_debug("Encountered unknown PDR#=0x%04x, (>=0x1000), assuming it's
bad.\n",
+pdrcode);
+ return 0;
}
--
2.2.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCHv4 1/8] devfreq: event: Add new devfreq_event class to provide basic data for devfreq governor
>
> Dear Myungjoo,
>
> Thanks for your review.
>
> On 12/18/2014 03:24 PM, MyungJoo Ham wrote:
> > Hi Chanwoo,
> >
> > I love the idea and I now have a little mechanical issues in your code.
> >
> >> ---
> >> drivers/devfreq/Kconfig | 2 +
> >> drivers/devfreq/Makefile| 5 +-
> >> drivers/devfreq/devfreq-event.c | 449
> >>
> >> drivers/devfreq/event/Makefile | 1 +
> >> include/linux/devfreq.h | 160 ++
> >> 5 files changed, 616 insertions(+), 1 deletion(-)
> >> create mode 100644 drivers/devfreq/devfreq-event.c
> >> create mode 100644 drivers/devfreq/event/Makefile
> >>
[]
>
> >
> >
> > [snip]
> >
> >> diff --git a/drivers/devfreq/devfreq-event.c
> >> b/drivers/devfreq/devfreq-event.c
> >> new file mode 100644
> >> index 000..0e1948e
> >> --- /dev/null
> >> +++ b/drivers/devfreq/devfreq-event.c
> >> @@ -0,0 +1,449 @@
> >> +/*
> >> + * devfreq-event: Generic DEVFREQ Event class driver
> >
> > DEVFREQ is a generic DVFS mechanism (or subsystem).
> >
> > Plus, I thought devfreq-event is considered to be a "framework"
> > for devfreq event class drivers. Am I mistaken?
>
> You're right. just "class driver" description is not proper.
> I'll modify the description of devfreq-event.c as following:
> or If you have other opinion, would you please let me know about it?
>
> devfreq-event: DEVFREQ-Event Framework to provide raw data of Non-CPU
> Devices.
devfreq-event: a framework to provide raw data and events of devfreq devices
should be enough.
[]
> > [snip / reversed maybe.. sorry]
> >
> >> +/**
> >> + * devfreq_event_is_enabled() - Check whether devfreq-event dev is
> >> enabled or
> >> + * not.
> >> + * @edev : the devfreq-event device
> >> + *
> >> + * Note that this function check whether devfreq-event dev is enabled or
> >> not.
> >> + * If return true, the devfreq-event dev is enabeld. If return false, the
> >> + * devfreq-event dev is disabled.
> >> + */
> >> +bool devfreq_event_is_enabled(struct devfreq_event_dev *edev)
> >> +{
> >> + bool enabled = false;
> >> +
> >> + if (!edev || !edev->desc)
> >> + return enabled;
> >> +
> >> + mutex_lock(>lock);
> >> +
> >> + if (edev->enable_count > 0)
> >> + enabled = true;
> >> +
> >> + if (edev->desc->ops && edev->desc->ops->is_enabled)
> >> + enabled |= edev->desc->ops->is_enabled(edev);
> >
> > What does it mean when enabled_count > 0 and ops->is_enabled() is false?
> > or..
> > What does it mean when enabled_count = 0 and ops->is_enabled() is true?
> >
> > If you do enable_count in the subsystem, why would we rely on
> > ops->is_enabled()? Are you assuming that a device MAY turn itself off
> > without any kernel control (ops->disable()) and it is still a correct
> > behabior?
>
> You're right. devfreq_event_is_enabled() has ambiguous operation according to
> your comment.
>
> I'll only control the enable_count in the subsystem without ops->is_enabled()
> and then remove the is_enabled function in the structre devfreq_event_ops.
>
> Best Regards,
> Chanwoo Choi
>
[Off-Topic]
The name of devfreq-event may look quite intersecting with irq-driven governors,
which are being proposed these days.
Although they may look intersecting, we can have them independently;
this as a sub-class and that as a governor. And we can consider to
provide a common infrastructure for irq-driven mechanisms in devfreq or
devfreq-event when we irq-driven DVFS become more general, which I
expect in 2 ~ 3 years.
So for now, both can go independently.
Cheers!
MyungJoo
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
[PATCH v4] tools lib traceevent: Add support for IP address formats
Add helpers for the following kernel formats:
%pi4 print an IPv4 address with leading zeros
%pI4 print an IPv4 address without leading zeros
%pi6 print an IPv6 address without colons
%pI6 print an IPv6 address with colons
%pI6c print an IPv6 address in compressed form with colons
%pISpc print an IP address from a sockaddr
Allows these formats to be used in tracepoints.
Quite a bit of this is adapted from code in lib/vsprintf.c.
v4:
- fixed pI6c description in git commit message per Valdis' comment
v3:
- use of 'c' and 'p' requires 'I'
v2:
- pass ptr+1 to print_ip_arg per Namhyung's comments
- added field length checks to sockaddr function
Signed-off-by: David Ahern
Cc: Namhyung Kim
Cc: Jiri Olsa
Cc: Steven Rostedt
---
tools/lib/traceevent/event-parse.c | 328 +
1 file changed, 328 insertions(+)
diff --git a/tools/lib/traceevent/event-parse.c
b/tools/lib/traceevent/event-parse.c
index cf3a44bf1ec3..afe20ed9fac8 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -32,6 +32,7 @@
#include
#include
+#include
#include "event-parse.h"
#include "event-utils.h"
@@ -4149,6 +4150,324 @@ static void print_mac_arg(struct trace_seq *s, int mac,
void *data, int size,
trace_seq_printf(s, fmt, buf[0], buf[1], buf[2], buf[3], buf[4],
buf[5]);
}
+static void print_ip4_addr(struct trace_seq *s, char i, unsigned char *buf)
+{
+ const char *fmt;
+
+ if (i == 'i')
+ fmt = "%03d.%03d.%03d.%03d";
+ else
+ fmt = "%d.%d.%d.%d";
+
+ trace_seq_printf(s, fmt, buf[0], buf[1], buf[2], buf[3]);
+}
+
+static inline bool ipv6_addr_v4mapped(const struct in6_addr *a)
+{
+ return ((unsigned long)(a->s6_addr32[0] | a->s6_addr32[1]) |
+ (unsigned long)(a->s6_addr32[2] ^ htonl(0x))) == 0UL;
+}
+
+static inline bool ipv6_addr_is_isatap(const struct in6_addr *addr)
+{
+ return (addr->s6_addr32[2] | htonl(0x0200)) == htonl(0x02005EFE);
+}
+
+static void print_ip6c_addr(struct trace_seq *s, unsigned char *addr)
+{
+ int i, j, range;
+ unsigned char zerolength[8];
+ int longest = 1;
+ int colonpos = -1;
+ uint16_t word;
+ uint8_t hi, lo;
+ bool needcolon = false;
+ bool useIPv4;
+ struct in6_addr in6;
+
+ memcpy(, addr, sizeof(struct in6_addr));
+
+ useIPv4 = ipv6_addr_v4mapped() || ipv6_addr_is_isatap();
+
+ memset(zerolength, 0, sizeof(zerolength));
+
+ if (useIPv4)
+ range = 6;
+ else
+ range = 8;
+
+ /* find position of longest 0 run */
+ for (i = 0; i < range; i++) {
+ for (j = i; j < range; j++) {
+ if (in6.s6_addr16[j] != 0)
+ break;
+ zerolength[i]++;
+ }
+ }
+ for (i = 0; i < range; i++) {
+ if (zerolength[i] > longest) {
+ longest = zerolength[i];
+ colonpos = i;
+ }
+ }
+ if (longest == 1) /* don't compress a single 0 */
+ colonpos = -1;
+
+ /* emit address */
+ for (i = 0; i < range; i++) {
+ if (i == colonpos) {
+ if (needcolon || i == 0)
+ trace_seq_printf(s, ":");
+ trace_seq_printf(s, ":");
+ needcolon = false;
+ i += longest - 1;
+ continue;
+ }
+ if (needcolon) {
+ trace_seq_printf(s, ":");
+ needcolon = false;
+ }
+ /* hex u16 without leading 0s */
+ word = ntohs(in6.s6_addr16[i]);
+ hi = word >> 8;
+ lo = word & 0xff;
+ if (hi)
+ trace_seq_printf(s, "%x%02x", hi, lo);
+ else
+ trace_seq_printf(s, "%x", lo);
+
+ needcolon = true;
+ }
+
+ if (useIPv4) {
+ if (needcolon)
+ trace_seq_printf(s, ":");
+ print_ip4_addr(s, 'I', _addr[12]);
+ }
+
+ return;
+}
+
+static void print_ip6_addr(struct trace_seq *s, char i, unsigned char *buf)
+{
+ int j;
+
+ for (j = 0; j < 16; j += 2) {
+ trace_seq_printf(s, "%02x%02x", buf[j], buf[j+1]);
+ if (i == 'I' && j < 14)
+ trace_seq_printf(s, ":");
+ }
+}
+
+/*
+ * %pi4 print an IPv4 address with leading zeros
+ * %pI4 print an IPv4 address without leading zeros
+ * %pi6 print an IPv6 address without colons
+ * %pI6 print an IPv6 address with colons
+ * %pI6c print an IPv6 address in compressed form with colons
+ * %pISpc print an IP address based on sockaddr; p adds port.
+ */
+static int print_ipv4_arg(struct
RE: [v3 23/26] KVM: Update Posted-Interrupts Descriptor when vCPU is preempted
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Paolo Bonzini
> Sent: Thursday, December 18, 2014 4:32 PM
> To: linux-kernel@vger.kernel.org
> Cc: io...@lists.linux-foundation.org; k...@vger.kernel.org;
> linux-kernel@vger.kernel.org; k...@vger.kernel.org
> Subject: Re: [v3 23/26] KVM: Update Posted-Interrupts Descriptor when vCPU
> is preempted
>
>
>
> On 18/12/2014 04:15, Wu, Feng wrote:
> > Thanks for your comments, Paolo!
> >
> > If we use u64 new_control, we cannot use new.sn any more.
> > Maybe we can change the struct pi_desc {} like this:
> >
> > typedef struct pid_control{
> > u64 on : 1,
> > sn : 1,
> > rsvd_1 : 13,
> > ndm : 1,
> > nv : 8,
> > rsvd_2 : 8,
> > ndst: 32;
> > }pid_control_t;
> >
> > struct pi_desc {
> > u32 pir[8]; /* Posted interrupt requested */
> > pid_control_t control;
>
> Probably something like this to keep the union:
>
> typedef union pid_control {
> u64 full;
> struct {
> u64 on : 1,
> ...
> } fields;
> };
>
> > u32 rsvd[6];
> > } __aligned(64);
> >
> >
> > Then we can define pid_control_t new_control, old_control. And use
> new_control.sn = 0.
> >
> > What is your opinon?
>
> Sure. Alternatively, keep using struct pi_desc new; just
> do not zero it, nor access any field outide the control word.
>
> Paolo
Yes, this is also a good idea. Thanks!
Thanks,
Feng
>
> --
> 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/
--
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: remove early_printk from a few arches? (blackfin, m68k, mips)
On Fri, 2014-12-19 at 01:43 +, Måns Rullgård wrote: > What exactly are you proposing to remove? Optionally compile out kernel/printk/printk.c:early_printk() even if CONFIG_EARLY_PRINTK is enabled. > I see no unused code related > to early printk (in any variant) under arch/mips. I think there could be yet another CONFIG option to specifically enable the early_printk function for the arches that use it. The kernel/printk/early_printk() function seems used only by arm/microblaze/tile/x86. -- 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 2/2] iommu: rockchip: Handle system-wide and runtime PM
On Thursday, December 18, 2014 11:28:58 PM Laurent Pinchart wrote: > Hi Kevin, > [cut] > > >> > > >> It would be better to be able to reference count the DMA engine from the > > >> bus master IMO and arguably you can use the runtime PM framework for > > >> that. Namely, give bus masters someting like > > >> > > >> pm_runtime_get_my_DMA_engine(bus_master_device) > > >> pm_runtime_put_my_DMA_engine(bus_master_device) > > >> > > >> and let them call these as they see fit. > > > > > > Please note that we're not talking about DMA engines here, but about > > > IOMMUs. DMA is involved through the DMA mapping API which hides the IOMMU > > > completely from the bus master drivers, not the DMA engine API. > > > > > > Exposing the IOMMU is something we want to avoid, but DMA mapping > > > start/stop operations could certainly be implemented. > > > > The problem with that is it only solves the IOMMU problem. We have a > > more generic PM dependency problem of which this IOMMU example is only a > > subset, so I think we need a more generic solution. > > I agree that a more generic solution is needed at least to support ACPI _DEP, > but that might not be optimal in the IOMMU use case as explained above. Well, since we need it anyway, why don't we implement it and then figure out if anything more specific needs to be done for the IOMMU case? -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[drm/fb-helper] BUG: unable to handle kernel paging request at 95d24c70
Hi Thierry, FYI, here is another bisect result. commit 7bf2844ed14de049a4ccec26eb3d8b4c3d5c1971 Author: Thierry Reding AuthorDate: Wed Dec 17 16:39:59 2014 +0100 Commit: Daniel Vetter CommitDate: Wed Dec 17 22:05:08 2014 +0100 drm/fb-helper: Propagate errors from initial config failure Make drm_fb_helper_initial_config() return an int rather than a bool so that the error can be properly propagated. While at it, update drivers to propagate errors further rather than just ignore them. Cc: David Airlie Cc: Daniel Vetter Cc: Patrik Jakobsson Cc: Rob Clark Cc: Tomi Valkeinen Cc: Alex Deucher Cc: Christian König Cc: Ben Skeggs Signed-off-by: Thierry Reding Reviewed-by: Alex Deucher Reviewed-by: Patrik Jakobsson Signed-off-by: Daniel Vetter +--+++---+ | | 7552e7dd95 | 7bf2844ed1 | next-20141218 | +--+++---+ | boot_successes | 60 | 0 | 0 | | boot_failures| 0 | 20 | 26 | | BUG:unable_to_handle_kernel | 0 | 20 | 26 | | Oops | 0 | 20 | 26 | | EIP_is_at_virt_to_head_page | 0 | 20 | 26 | | Kernel_panic-not_syncing:Fatal_exception | 0 | 20 | 26 | | backtrace:__pci_register_driver | 0 | 20 | 26 | | backtrace:drm_pci_init | 0 | 20 | 26 | | backtrace:cirrus_init| 0 | 20 | 26 | | backtrace:kernel_init_freeable | 0 | 20 | 26 | +--+++---+ [1.509413] cirrusdrmfb: enable CONFIG_FB_LITTLE_ENDIAN to support this framebuffer [1.510493] [drm:cirrus_modeset_init] *ERROR* cirrus_fbdev_init failed [1.511405] cirrus :00:02.0: Fatal error during modeset init: -22 [1.513064] BUG: unable to handle kernel paging request at 95d24c70 [1.513775] IP: [<8109e956>] virt_to_head_page+0x15/0x2a [1.513775] *pdpt = 01c48001 *pde = [1.513775] Oops: [#1] DEBUG_PAGEALLOC [1.513775] CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-rc4-00653-g7bf2844 #26 [1.513775] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [1.513775] task: 8010 ti: 80072000 task.ti: 80072000 [1.513775] EIP: 0060:[<8109e956>] EFLAGS: 00010282 CPU: 0 [1.513775] EIP is at virt_to_head_page+0x15/0x2a [1.513775] EAX: 6b6b6b6b EBX: 6b6b6b6b ECX: 00110005 EDX: 95d24c70 [1.513775] ESI: EDI: 9208dfc4 EBP: 80073d8c ESP: 80073d8c [1.513775] DS: 007b ES: 007b FS: GS: SS: 0068 [1.513775] CR0: 8005003b CR2: 95d24c70 CR3: 01c4c000 CR4: 06b0 [1.513775] Stack: [1.513775] 80073dac 810a0c1a 81098f98 81098f98 023f 91196db0 9208dfc4 [1.513775] 80073dc0 8136b055 91196db0 9208a2c0 9208dfc4 80073dcc 8136b6c1 91196db0 [1.513775] 80073de4 813fd7d4 9174ec24 9208a2c0 9208df90 9208a2c0 80073df0 813fd037 [1.513775] Call Trace: [1.513775] [<810a0c1a>] kfree+0x19/0xc4 [1.513775] [<81098f98>] ? __vunmap+0x8f/0x97 [1.513775] [<81098f98>] ? __vunmap+0x8f/0x97 [1.513775] [<8136b055>] drm_fb_helper_crtc_free+0x1a/0x5a [1.513775] [<8136b6c1>] drm_fb_helper_fini+0x4f/0x54 [1.513775] [<813fd7d4>] cirrus_fbdev_fini+0x9a/0xcb [1.513775] [<813fd037>] cirrus_modeset_fini+0xb/0x1f [1.513775] [<813fc2fb>] cirrus_driver_unload+0x15/0x37 [1.513775] [<813fc3c8>] cirrus_driver_load+0xab/0xb5 [1.513775] [<813730cc>] drm_dev_register+0x69/0xcb [1.513775] [<8137438e>] drm_get_pci_dev+0xc8/0x15c [1.513775] [<813fd11a>] cirrus_pci_probe+0xbf/0xc7 [1.513775] [<8127c6b6>] pci_device_probe+0x45/0x7f [1.513775] [<81428648>] driver_probe_device+0x83/0x175 [1.513775] [<814287b4>] __driver_attach+0x4e/0x6a [1.513775] [<81427490>] bus_for_each_dev+0x4e/0x6b [1.513775] [<81428850>] driver_attach+0x14/0x16 [1.513775] [<81428766>] ? __device_attach+0x2c/0x2c [1.513775] [<81427ac9>] bus_add_driver+0xc5/0x175 [1.513775] [<81bed76c>] ? i915_init+0x69/0x69 [1.513775] [<81428b8c>] driver_register+0x6f/0xa4 [1.513775] [<81bed76c>] ? i915_init+0x69/0x69 [1.513775] [<8127c589>] __pci_register_driver+0x45/0x48 [1.513775] [<81374469>] drm_pci_init+0x47/0xb3 [1.513775] [<81bed76
[PATCH v2 1/7] gpu: ipu-di: Add ipu_di_adjust_videomode()
From: Jiada Wang
On some monitors, high resolution modes are not working, exhibiting
pixel column truncation problems (for example, 1280x1024 displays as
1280x1022).
The function ipu_di_adjust_videomode() aims to fix these issues by
adjusting a passed videomode to IPU restrictions. The function can
be called from the drm_crtc_helper_funcs->mode_fixup() methods.
Signed-off-by: Jiada Wang
Signed-off-by: Deepak Das
Signed-off-by: Steve Longerbeam
---
drivers/gpu/ipu-v3/ipu-di.c | 29 +
include/video/imx-ipu-v3.h |2 ++
2 files changed, 31 insertions(+)
diff --git a/drivers/gpu/ipu-v3/ipu-di.c b/drivers/gpu/ipu-v3/ipu-di.c
index c490ba4..46f9570 100644
--- a/drivers/gpu/ipu-v3/ipu-di.c
+++ b/drivers/gpu/ipu-v3/ipu-di.c
@@ -511,6 +511,35 @@ static void ipu_di_config_clock(struct ipu_di *di,
clk_get_rate(di->clk_di_pixel) / (clkgen0 >> 4));
}
+/*
+ * This function is called to adjust a video mode to IPU restrictions.
+ * It is meant to be called from drm crtc mode_fixup() methods.
+ */
+int ipu_di_adjust_videomode(struct ipu_di *di, struct videomode *mode)
+{
+ u32 diff;
+
+ if (mode->vfront_porch >= 2)
+ return 0;
+
+ diff = 2 - mode->vfront_porch;
+
+ if (mode->vback_porch >= diff) {
+ mode->vfront_porch = 2;
+ mode->vback_porch -= diff;
+ } else if (mode->vsync_len > diff) {
+ mode->vfront_porch = 2;
+ mode->vsync_len = mode->vsync_len - diff;
+ } else {
+ dev_warn(di->ipu->dev, "failed to adjust videomode\n");
+ return -EINVAL;
+ }
+
+ dev_warn(di->ipu->dev, "videomode adapted for IPU restrictions\n");
+ return 0;
+}
+EXPORT_SYMBOL_GPL(ipu_di_adjust_videomode);
+
int ipu_di_init_sync_panel(struct ipu_di *di, struct ipu_di_signal_cfg *sig)
{
u32 reg;
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index c74bf4a..d333d54 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
struct ipu_soc;
@@ -236,6 +237,7 @@ void ipu_di_put(struct ipu_di *);
int ipu_di_disable(struct ipu_di *);
int ipu_di_enable(struct ipu_di *);
int ipu_di_get_num(struct ipu_di *);
+int ipu_di_adjust_videomode(struct ipu_di *di, struct videomode *mode);
int ipu_di_init_sync_panel(struct ipu_di *, struct ipu_di_signal_cfg *sig);
/*
--
1.7.9.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 v2 0/7] imx-drm: ipuv3-crtc: Implement mode_fixup
This patchset implements ->mode_fixup() in the imx ipuv3-crtc driver, using a new support function ipu_di_adjust_videomode(). This new function needs to be subsystem independent, so it accepts a video mode as a 'struct videomode'. Hence ipu-crtc ->mode_fixup() needs another support function to convert a drm_display_mode to a videomode before passing the mode to ipu_di_adjust_videomode() for fixup. Also some related code cleanup: 'struct ipu_di_signal_cfg' should use 'struct videomode' for mode timings. Jiada Wang (1): gpu: ipu-di: Add ipu_di_adjust_videomode() Steve Longerbeam (6): gpu: ipu-di: remove some non-functional code drm_modes: add videomode_from_drm_display_mode imx-drm: ipuv3-crtc: Implement mode_fixup imx-drm: encoder prepare/mode_set must use adjusted mode gpu: ipu-v3: Use videomode in struct ipu_di_signal_cfg gpu: ipu-di: Switch to DIV_ROUND_CLOSEST for DI clock divider calc drivers/gpu/drm/drm_modes.c| 40 +++ drivers/gpu/drm/imx/imx-hdmi.c |4 +- drivers/gpu/drm/imx/imx-ldb.c |6 +- drivers/gpu/drm/imx/imx-tve.c |4 +- drivers/gpu/drm/imx/ipuv3-crtc.c | 38 +- drivers/gpu/drm/imx/parallel-display.c |4 +- drivers/gpu/ipu-v3/ipu-di.c| 121 +++- include/drm/drm_modes.h|2 + include/video/imx-ipu-v3.h | 21 ++ 9 files changed, 147 insertions(+), 93 deletions(-) -- 1.7.9.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 v2 3/7] drm_modes: add videomode_from_drm_display_mode
Add conversion from drm_display_mode to videomode.
Signed-off-by: Steve Longerbeam
---
drivers/gpu/drm/drm_modes.c | 40
include/drm/drm_modes.h |2 ++
2 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 6d8b941..583a391 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -615,6 +615,46 @@ void drm_display_mode_from_videomode(const struct
videomode *vm,
}
EXPORT_SYMBOL_GPL(drm_display_mode_from_videomode);
+/**
+ * videomode_from_drm_display_mode - fill in @vm using @dmode,
+ * @dmode: drm_display_mode structure to use as source
+ * @vm: videomode structure to use as destination
+ *
+ * Fills out @vm using the display mode specified in @dmode.
+ */
+void videomode_from_drm_display_mode(const struct drm_display_mode *dmode,
+struct videomode *vm)
+{
+ vm->hactive = dmode->hdisplay;
+ vm->hfront_porch = dmode->hsync_start - dmode->hdisplay;
+ vm->hsync_len = dmode->hsync_end - dmode->hsync_start;
+ vm->hback_porch = dmode->htotal - dmode->hsync_end;
+
+ vm->vactive = dmode->vdisplay;
+ vm->vfront_porch = dmode->vsync_start - dmode->vdisplay;
+ vm->vsync_len = dmode->vsync_end - dmode->vsync_start;
+ vm->vback_porch = dmode->vtotal - dmode->vsync_end;
+
+ vm->pixelclock = dmode->clock * 1000;
+
+ vm->flags = 0;
+ if (dmode->flags & DRM_MODE_FLAG_PHSYNC)
+ vm->flags |= DISPLAY_FLAGS_HSYNC_HIGH;
+ else if (dmode->flags & DRM_MODE_FLAG_NHSYNC)
+ vm->flags |= DISPLAY_FLAGS_HSYNC_LOW;
+ if (dmode->flags & DRM_MODE_FLAG_PVSYNC)
+ vm->flags |= DISPLAY_FLAGS_VSYNC_HIGH;
+ else if (dmode->flags & DRM_MODE_FLAG_NVSYNC)
+ vm->flags |= DISPLAY_FLAGS_VSYNC_LOW;
+ if (dmode->flags & DRM_MODE_FLAG_INTERLACE)
+ vm->flags |= DISPLAY_FLAGS_INTERLACED;
+ if (dmode->flags & DRM_MODE_FLAG_DBLSCAN)
+ vm->flags |= DISPLAY_FLAGS_DOUBLESCAN;
+ if (dmode->flags & DRM_MODE_FLAG_DBLCLK)
+ vm->flags |= DISPLAY_FLAGS_DOUBLECLK;
+}
+EXPORT_SYMBOL_GPL(videomode_from_drm_display_mode);
+
#ifdef CONFIG_OF
/**
* of_get_drm_display_mode - get a drm_display_mode from devicetree
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 91d0582..60c0144 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -197,6 +197,8 @@ struct drm_display_mode *drm_gtf_mode_complex(struct
drm_device *dev,
int GTF_K, int GTF_2J);
void drm_display_mode_from_videomode(const struct videomode *vm,
struct drm_display_mode *dmode);
+void videomode_from_drm_display_mode(const struct drm_display_mode *dmode,
+struct videomode *vm);
int of_get_drm_display_mode(struct device_node *np,
struct drm_display_mode *dmode,
int index);
--
1.7.9.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: [PATCHv v3] tools lib traceevent: Add support for IP address formats
On 12/18/14 7:00 PM, valdis.kletni...@vt.edu wrote: On Thu, 18 Dec 2014 18:43:10 -0700, David Ahern said: Adds helper for following kernel formats: %pi4 print an IPv4 address with leading zeros %pI4 print an IPv4 address without leading zeros %pi6 print an IPv6 address without colons %pI6 print an IPv6 address with colons %pI6c print an IPv6 address with colons %pI6c print an IPv6 address *in compressed form* with colons. damn it. I misunderstood your comment before. Thanks for the follow up. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/7] imx-drm: ipuv3-crtc: Implement mode_fixup
Ask the IPU display interface, via ipu_di_adjust_videomode(), to
adjust a video mode to meet any DI restrictions. The function takes
a subsystem independent videomode, so the drm_display_mode must be
converted to videomode first, and then the adjusted mode converted
back to a drm_display_mode.
Signed-off-by: Steve Longerbeam
---
drivers/gpu/drm/imx/ipuv3-crtc.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 11e84a2..fb16026 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -242,6 +242,18 @@ static bool ipu_crtc_mode_fixup(struct drm_crtc *crtc,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
+ struct ipu_crtc *ipu_crtc = to_ipu_crtc(crtc);
+ struct videomode vm;
+ int ret;
+
+ videomode_from_drm_display_mode(adjusted_mode, );
+
+ ret = ipu_di_adjust_videomode(ipu_crtc->di, );
+ if (ret)
+ return false;
+
+ drm_display_mode_from_videomode(, adjusted_mode);
+
return true;
}
--
1.7.9.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 v2 7/7] gpu: ipu-di: Switch to DIV_ROUND_CLOSEST for DI clock divider calc
We can use the DIV_ROUND_CLOSEST() macro when calculating the DI clock divider, rounded to nearest int. Suggested-by: Philipp Zabel Signed-off-by: Steve Longerbeam --- drivers/gpu/ipu-v3/ipu-di.c |9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/ipu-v3/ipu-di.c b/drivers/gpu/ipu-v3/ipu-di.c index d95fbd0..b61d6be 100644 --- a/drivers/gpu/ipu-v3/ipu-di.c +++ b/drivers/gpu/ipu-v3/ipu-di.c @@ -440,8 +440,7 @@ static void ipu_di_config_clock(struct ipu_di *di, clk_set_rate(clk, sig->mode.pixelclock); in_rate = clk_get_rate(clk); - div = (in_rate + sig->mode.pixelclock / 2) / - sig->mode.pixelclock; + div = DIV_ROUND_CLOSEST(in_rate, sig->mode.pixelclock); if (div == 0) div = 1; @@ -459,8 +458,7 @@ static void ipu_di_config_clock(struct ipu_di *di, unsigned div, error; clkrate = clk_get_rate(di->clk_ipu); - div = (clkrate + sig->mode.pixelclock / 2) / - sig->mode.pixelclock; + div = DIV_ROUND_CLOSEST(clkrate, sig->mode.pixelclock); rate = clkrate / div; error = rate / (sig->mode.pixelclock / 1000); @@ -482,8 +480,7 @@ static void ipu_di_config_clock(struct ipu_di *di, clk_set_rate(clk, sig->mode.pixelclock); in_rate = clk_get_rate(clk); - div = (in_rate + sig->mode.pixelclock / 2) / - sig->mode.pixelclock; + div = DIV_ROUND_CLOSEST(in_rate, sig->mode.pixelclock); if (div == 0) div = 1; -- 1.7.9.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 v2 6/7] gpu: ipu-v3: Use videomode in struct ipu_di_signal_cfg
This patch changes struct ipu_di_signal_cfg to use struct videomode
to define video timings and flags.
Signed-off-by: Steve Longerbeam
---
drivers/gpu/drm/imx/ipuv3-crtc.c | 26 +++
drivers/gpu/ipu-v3/ipu-di.c | 89 --
include/video/imx-ipu-v3.h | 19 ++--
3 files changed, 56 insertions(+), 78 deletions(-)
diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index fb16026..1ca6492 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -158,35 +158,19 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
out_pixel_fmt = ipu_crtc->interface_pix_fmt;
- if (mode->flags & DRM_MODE_FLAG_INTERLACE)
- sig_cfg.interlaced = 1;
- if (mode->flags & DRM_MODE_FLAG_PHSYNC)
- sig_cfg.Hsync_pol = 1;
- if (mode->flags & DRM_MODE_FLAG_PVSYNC)
- sig_cfg.Vsync_pol = 1;
-
sig_cfg.enable_pol = 1;
sig_cfg.clk_pol = 0;
- sig_cfg.width = mode->hdisplay;
- sig_cfg.height = mode->vdisplay;
sig_cfg.pixel_fmt = out_pixel_fmt;
- sig_cfg.h_start_width = mode->htotal - mode->hsync_end;
- sig_cfg.h_sync_width = mode->hsync_end - mode->hsync_start;
- sig_cfg.h_end_width = mode->hsync_start - mode->hdisplay;
-
- sig_cfg.v_start_width = mode->vtotal - mode->vsync_end;
- sig_cfg.v_sync_width = mode->vsync_end - mode->vsync_start;
- sig_cfg.v_end_width = mode->vsync_start - mode->vdisplay;
- sig_cfg.pixelclock = mode->clock * 1000;
sig_cfg.clkflags = ipu_crtc->di_clkflags;
-
sig_cfg.v_to_h_sync = 0;
-
sig_cfg.hsync_pin = ipu_crtc->di_hsync_pin;
sig_cfg.vsync_pin = ipu_crtc->di_vsync_pin;
- ret = ipu_dc_init_sync(ipu_crtc->dc, ipu_crtc->di, sig_cfg.interlaced,
- out_pixel_fmt, mode->hdisplay);
+ videomode_from_drm_display_mode(mode, _cfg.mode);
+
+ ret = ipu_dc_init_sync(ipu_crtc->dc, ipu_crtc->di,
+ mode->flags & DRM_MODE_FLAG_INTERLACE,
+ out_pixel_fmt, mode->hdisplay);
if (ret) {
dev_err(ipu_crtc->dev,
"initializing display controller failed with
%d\n",
diff --git a/drivers/gpu/ipu-v3/ipu-di.c b/drivers/gpu/ipu-v3/ipu-di.c
index 41df8d7..d95fbd0 100644
--- a/drivers/gpu/ipu-v3/ipu-di.c
+++ b/drivers/gpu/ipu-v3/ipu-di.c
@@ -207,10 +207,10 @@ static void ipu_di_sync_config(struct ipu_di *di, struct
di_sync_config *config,
static void ipu_di_sync_config_interlaced(struct ipu_di *di,
struct ipu_di_signal_cfg *sig)
{
- u32 h_total = sig->width + sig->h_sync_width +
- sig->h_start_width + sig->h_end_width;
- u32 v_total = sig->height + sig->v_sync_width +
- sig->v_start_width + sig->v_end_width;
+ u32 h_total = sig->mode.hactive + sig->mode.hsync_len +
+ sig->mode.hback_porch + sig->mode.hfront_porch;
+ u32 v_total = sig->mode.vactive + sig->mode.vsync_len +
+ sig->mode.vback_porch + sig->mode.vfront_porch;
u32 reg;
struct di_sync_config cfg[] = {
{
@@ -229,13 +229,13 @@ static void ipu_di_sync_config_interlaced(struct ipu_di
*di,
}, {
.run_count = v_total / 2 - 1,
.run_src = DI_SYNC_HSYNC,
- .offset_count = sig->v_start_width,
+ .offset_count = sig->mode.vback_porch,
.offset_src = DI_SYNC_HSYNC,
.repeat_count = 2,
.cnt_clr_src = DI_SYNC_VSYNC,
}, {
.run_src = DI_SYNC_HSYNC,
- .repeat_count = sig->height / 2,
+ .repeat_count = sig->mode.vactive / 2,
.cnt_clr_src = 4,
}, {
.run_count = v_total - 1,
@@ -249,9 +249,9 @@ static void ipu_di_sync_config_interlaced(struct ipu_di *di,
.cnt_clr_src = DI_SYNC_VSYNC,
}, {
.run_src = DI_SYNC_CLK,
- .offset_count = sig->h_start_width,
+ .offset_count = sig->mode.hback_porch,
.offset_src = DI_SYNC_CLK,
- .repeat_count = sig->width,
+ .repeat_count = sig->mode.hactive,
.cnt_clr_src = 5,
}, {
.run_count = v_total - 1,
@@ -277,10 +277,10 @@ static void ipu_di_sync_config_interlaced(struct ipu_di
*di,
static void ipu_di_sync_config_noninterlaced(struct ipu_di *di,
struct ipu_di_signal_cfg *sig, int div)
{
- u32 h_total = sig->width + sig->h_sync_width + sig->h_start_width +
- sig->h_end_width;
- u32 v_total = sig->height +
[PATCH v2 2/7] gpu: ipu-di: remove some non-functional code
h_total and v_total were calculated in ipu_di_init_sync_panel() but never actually used. Remove. Signed-off-by: Steve Longerbeam --- drivers/gpu/ipu-v3/ipu-di.c |6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/gpu/ipu-v3/ipu-di.c b/drivers/gpu/ipu-v3/ipu-di.c index 46f9570..41df8d7 100644 --- a/drivers/gpu/ipu-v3/ipu-di.c +++ b/drivers/gpu/ipu-v3/ipu-di.c @@ -545,7 +545,6 @@ int ipu_di_init_sync_panel(struct ipu_di *di, struct ipu_di_signal_cfg *sig) u32 reg; u32 di_gen, vsync_cnt; u32 div; - u32 h_total, v_total; dev_dbg(di->ipu->dev, "disp %d: panel size = %d x %d\n", di->id, sig->width, sig->height); @@ -553,11 +552,6 @@ int ipu_di_init_sync_panel(struct ipu_di *di, struct ipu_di_signal_cfg *sig) if ((sig->v_sync_width == 0) || (sig->h_sync_width == 0)) return -EINVAL; - h_total = sig->width + sig->h_sync_width + sig->h_start_width + - sig->h_end_width; - v_total = sig->height + sig->v_sync_width + sig->v_start_width + - sig->v_end_width; - dev_dbg(di->ipu->dev, "Clocks: IPU %luHz DI %luHz Needed %luHz\n", clk_get_rate(di->clk_ipu), clk_get_rate(di->clk_di), -- 1.7.9.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/
[hisi:integration-hilt-linux-linaro 17/28] drivers/input/touchscreen/atmel_mXT224E.c:460:5: sparse: symbol 'i2c_atmel_read' was not declared. Should it be static?
tree: git://github.com/hisilicon/linux-hisi integration-hilt-linux-linaro head: 791a2af480ea27735b4669c623b665c5bfea9b5c commit: d7e9caafdf706341b4165d0a8c2089e60dcebc68 [17/28] Input: enable touch atmel_mXT224E reproduce: # apt-get install sparse git checkout d7e9caafdf706341b4165d0a8c2089e60dcebc68 make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> drivers/input/touchscreen/atmel_mXT224E.c:460:5: sparse: symbol >> 'i2c_atmel_read' was not declared. Should it be static? >> drivers/input/touchscreen/atmel_mXT224E.c:499:28: sparse: Variable length >> array is used. >> drivers/input/touchscreen/atmel_mXT224E.c:496:5: sparse: symbol >> 'i2c_atmel_write' was not declared. Should it be static? >> drivers/input/touchscreen/atmel_mXT224E.c:532:5: sparse: symbol >> 'i2c_atmel_write_byte_data' was not declared. Should it be static? >> drivers/input/touchscreen/atmel_mXT224E.c:538:10: sparse: symbol >> 'get_object_address' was not declared. Should it be static? >> drivers/input/touchscreen/atmel_mXT224E.c:547:9: sparse: symbol >> 'get_object_size' was not declared. Should it be static? >> drivers/input/touchscreen/atmel_mXT224E.c:557:9: sparse: symbol >> 'get_object_size_from_address' was not declared. Should it be static? >> drivers/input/touchscreen/atmel_mXT224E.c:847:32: sparse: symbol >> 'atmel_ts_get_pdata' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] tty: 8250_omap: Replace CONFIG_PM_RUNTIME with CONFIG_PM
On Thursday, December 18, 2014 05:57:17 PM Greg Kroah-Hartman wrote: > On Fri, Dec 19, 2014 at 02:55:00AM +0100, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > The 8250_omap serial driver is a new user of CONFIG_PM_RUNTIME. > > > > However, after commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if > > PM_SLEEP is selected) PM_RUNTIME is always set if PM is set, so > > #ifdef blocks depending on CONFIG_PM_RUNTIME may now be changed to > > depend on CONFIG_PM. > > > > Replace CONFIG_PM_RUNTIME with CONFIG_PM in 8250_omap.c. > > > > Signed-off-by: Rafael J. Wysocki > > --- > > > > Please let me know if there are any objections against pushing this through > > the linux-pm tree. > > Please do: > > Acked-by: Greg Kroah-Hartman Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 5/7] imx-drm: encoder prepare/mode_set must use adjusted mode
The encoder ->prepare() and ->mode_set() methods need to use the
hw adjusted mode, not the original mode.
Signed-off-by: Steve Longerbeam
---
drivers/gpu/drm/imx/imx-hdmi.c |4 ++--
drivers/gpu/drm/imx/imx-ldb.c |6 +++---
drivers/gpu/drm/imx/imx-tve.c |4 ++--
drivers/gpu/drm/imx/parallel-display.c |4 ++--
4 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-hdmi.c b/drivers/gpu/drm/imx/imx-hdmi.c
index aaec6b2..32116cc 100644
--- a/drivers/gpu/drm/imx/imx-hdmi.c
+++ b/drivers/gpu/drm/imx/imx-hdmi.c
@@ -1417,8 +1417,8 @@ static struct drm_encoder
*imx_hdmi_connector_best_encoder(struct drm_connector
}
static void imx_hdmi_encoder_mode_set(struct drm_encoder *encoder,
- struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+ struct drm_display_mode *orig_mode,
+ struct drm_display_mode *mode)
{
struct imx_hdmi *hdmi = container_of(encoder, struct imx_hdmi, encoder);
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 4662e00..5b9c875 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -168,7 +168,7 @@ static void imx_ldb_encoder_prepare(struct drm_encoder
*encoder)
{
struct imx_ldb_channel *imx_ldb_ch = enc_to_imx_ldb_ch(encoder);
struct imx_ldb *ldb = imx_ldb_ch->ldb;
- struct drm_display_mode *mode = >crtc->mode;
+ struct drm_display_mode *mode = >crtc->hwmode;
u32 pixel_fmt;
unsigned long serial_clk;
unsigned long di_clk = mode->clock * 1000;
@@ -246,8 +246,8 @@ static void imx_ldb_encoder_commit(struct drm_encoder
*encoder)
}
static void imx_ldb_encoder_mode_set(struct drm_encoder *encoder,
-struct drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode)
+struct drm_display_mode *orig_mode,
+struct drm_display_mode *mode)
{
struct imx_ldb_channel *imx_ldb_ch = enc_to_imx_ldb_ch(encoder);
struct imx_ldb *ldb = imx_ldb_ch->ldb;
diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c
index 42c651b..9709bf9a 100644
--- a/drivers/gpu/drm/imx/imx-tve.c
+++ b/drivers/gpu/drm/imx/imx-tve.c
@@ -312,8 +312,8 @@ static void imx_tve_encoder_prepare(struct drm_encoder
*encoder)
}
static void imx_tve_encoder_mode_set(struct drm_encoder *encoder,
-struct drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode)
+struct drm_display_mode *orig_mode,
+struct drm_display_mode *mode)
{
struct imx_tve *tve = enc_to_tve(encoder);
unsigned long rounded_rate;
diff --git a/drivers/gpu/drm/imx/parallel-display.c
b/drivers/gpu/drm/imx/parallel-display.c
index 015a454..d0842a4 100644
--- a/drivers/gpu/drm/imx/parallel-display.c
+++ b/drivers/gpu/drm/imx/parallel-display.c
@@ -131,8 +131,8 @@ static void imx_pd_encoder_commit(struct drm_encoder
*encoder)
}
static void imx_pd_encoder_mode_set(struct drm_encoder *encoder,
-struct drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode)
+struct drm_display_mode *orig_mode,
+struct drm_display_mode *mode)
{
}
--
1.7.9.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: [PATCHv v3] tools lib traceevent: Add support for IP address formats
On Thu, 18 Dec 2014 18:43:10 -0700, David Ahern said: > Adds helper for following kernel formats: > %pi4 print an IPv4 address with leading zeros > %pI4 print an IPv4 address without leading zeros > %pi6 print an IPv6 address without colons > %pI6 print an IPv6 address with colons > %pI6c print an IPv6 address with colons %pI6c print an IPv6 address *in compressed form* with colons. pgpg39qZVdDyJ.pgp Description: PGP signature
