Fixes the following W=1 kernel build warning(s):
drivers/usb/host/xhci-debugfs.c:128:2: warning: function ‘xhci_debugfs_regset’ might be a candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format]
128 | vsnprintf(rgs->name, sizeof(rgs->name), fmt, args);
| ^~~~~~~~~
Cc: Mathias Nyman <mathias.nyman@intel.com>
Cc: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200703174148.2749969-19-lee.jones@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Descriptions were missing for 'ci' almost throughout. There was
one instance of over-documenting. Finally one function argument
was incorrectly documented (probably down to bitrot).
Fixes the following W=1 kernel build warning(s):
drivers/usb/chipidea/udc.c:245: warning: Function parameter or member 'ci' not described in 'hw_port_is_high_speed'
drivers/usb/chipidea/udc.c:271: warning: Function parameter or member 'ci' not described in 'hw_test_and_clear_intr_active'
drivers/usb/chipidea/udc.c:285: warning: Function parameter or member 'ci' not described in 'hw_test_and_clear_setup_guard'
drivers/usb/chipidea/udc.c:296: warning: Function parameter or member 'ci' not described in 'hw_test_and_set_setup_guard'
drivers/usb/chipidea/udc.c:321: warning: Function parameter or member 'ci' not described in 'hw_usb_reset'
drivers/usb/chipidea/udc.c:628: warning: Excess function parameter 'ci' description in 'free_pending_td'
drivers/usb/chipidea/udc.c:655: warning: Function parameter or member 'hwep' not described in '_hardware_dequeue'
drivers/usb/chipidea/udc.c:655: warning: Excess function parameter 'gadget' description in '_hardware_dequeue'
Cc: Peter Chen <Peter.Chen@nxp.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200703174148.2749969-18-lee.jones@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Demote xhci-dbgtty's file header to a standard comment block.
Fixes the following W=1 kernel build warning(s):
drivers/usb/host/xhci-dbgtty.c:19: warning: Function parameter or member 'port' not described in 'dbc_send_packet'
drivers/usb/host/xhci-dbgtty.c:19: warning: Function parameter or member 'packet' not described in 'dbc_send_packet'
drivers/usb/host/xhci-dbgtty.c:19: warning: Function parameter or member 'size' not described in 'dbc_send_packet'
Cc: Mathias Nyman <mathias.nyman@intel.com>
Cc: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200703174148.2749969-17-lee.jones@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Demote xhci-dbgcap's file header to a standard comment block.
Fixes the following W=1 kernel build warning(s):
drivers/usb/host/xhci-dbgcap.c:20: warning: Function parameter or member 'xhci' not described in 'dbc_dma_alloc_coherent'
drivers/usb/host/xhci-dbgcap.c:20: warning: Function parameter or member 'size' not described in 'dbc_dma_alloc_coherent'
drivers/usb/host/xhci-dbgcap.c:20: warning: Function parameter or member 'dma_handle' not described in 'dbc_dma_alloc_coherent'
drivers/usb/host/xhci-dbgcap.c:20: warning: Function parameter or member 'flags' not described in 'dbc_dma_alloc_coherent'
Cc: Mathias Nyman <mathias.nyman@intel.com>
Cc: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200703174148.2749969-16-lee.jones@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
No attempt has been made to document the demoted function here.
Fixes the following W=1 kernel build warning(s):
drivers/usb/host/xhci-mem.c:365: warning: Function parameter or member 'xhci' not described in 'xhci_ring_alloc'
drivers/usb/host/xhci-mem.c:365: warning: Function parameter or member 'num_segs' not described in 'xhci_ring_alloc'
drivers/usb/host/xhci-mem.c:365: warning: Function parameter or member 'cycle_state' not described in 'xhci_ring_alloc'
drivers/usb/host/xhci-mem.c:365: warning: Function parameter or member 'type' not described in 'xhci_ring_alloc'
drivers/usb/host/xhci-mem.c:365: warning: Function parameter or member 'max_packet' not described in 'xhci_ring_alloc'
drivers/usb/host/xhci-mem.c:365: warning: Function parameter or member 'flags' not described in 'xhci_ring_alloc'
Cc: Mathias Nyman <mathias.nyman@intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200703174148.2749969-15-lee.jones@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
No attempt has been made to document the demoted function here.
Fixes the following W=1 kernel build warning(s):
drivers/usb/host/xhci.c:1285: warning: Function parameter or member 'desc' not described in 'xhci_get_endpoint_index'
Cc: Mathias Nyman <mathias.nyman@intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200703174148.2749969-14-lee.jones@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Help with adding the odd description where they have been omitted or
where the format isn't quite right. Demote all function headers which
are lacking any attempt of describing their arguments.
Fixes the following W=1 kernel build warning(s):
drivers/usb/chipidea/udc.c:645: warning: Function parameter or member 'hwreq' not described in '_hardware_dequeue'
drivers/usb/chipidea/udc.c:645: warning: Excess function parameter 'gadget' description in '_hardware_dequeue'
drivers/usb/chipidea/udc.c:1326: warning: Function parameter or member 'ep' not described in 'ep_enable'
drivers/usb/chipidea/udc.c:1326: warning: Function parameter or member 'desc' not described in 'ep_enable'
drivers/usb/chipidea/udc.c:1393: warning: Function parameter or member 'ep' not described in 'ep_disable'
drivers/usb/chipidea/udc.c:1433: warning: Function parameter or member 'ep' not described in 'ep_alloc_request'
drivers/usb/chipidea/udc.c:1433: warning: Function parameter or member 'gfp_flags' not described in 'ep_alloc_request'
drivers/usb/chipidea/udc.c:1454: warning: Function parameter or member 'ep' not described in 'ep_free_request'
drivers/usb/chipidea/udc.c:1454: warning: Function parameter or member 'req' not described in 'ep_free_request'
drivers/usb/chipidea/udc.c:1488: warning: Function parameter or member 'ep' not described in 'ep_queue'
drivers/usb/chipidea/udc.c:1488: warning: Function parameter or member 'req' not described in 'ep_queue'
drivers/usb/chipidea/udc.c:1488: warning: Function parameter or member 'gfp_flags' not described in 'ep_queue'
drivers/usb/chipidea/udc.c:1512: warning: Function parameter or member 'ep' not described in 'ep_dequeue'
drivers/usb/chipidea/udc.c:1512: warning: Function parameter or member 'req' not described in 'ep_dequeue'
drivers/usb/chipidea/udc.c:1556: warning: Function parameter or member 'ep' not described in 'ep_set_halt'
drivers/usb/chipidea/udc.c:1556: warning: Function parameter or member 'value' not described in 'ep_set_halt'
drivers/usb/chipidea/udc.c:1566: warning: Function parameter or member 'ep' not described in 'ep_set_wedge'
drivers/usb/chipidea/udc.c:1586: warning: Function parameter or member 'ep' not described in 'ep_fifo_flush'
drivers/usb/chipidea/udc.c:1610: warning: cannot understand function prototype: 'const struct usb_ep_ops usb_ep_ops = '
drivers/usb/chipidea/udc.c:1629: warning: Function parameter or member '_gadget' not described in 'ci_hdrc_gadget_connect'
drivers/usb/chipidea/udc.c:1629: warning: Function parameter or member 'is_active' not described in 'ci_hdrc_gadget_connect'
drivers/usb/chipidea/udc.c:1780: warning: cannot understand function prototype: 'const struct usb_gadget_ops usb_gadget_ops = '
drivers/usb/chipidea/udc.c:1931: warning: Function parameter or member 'gadget' not described in 'ci_udc_stop'
drivers/usb/chipidea/udc.c:1965: warning: Function parameter or member 'ci' not described in 'udc_irq'
drivers/usb/chipidea/udc.c:2095: warning: Function parameter or member 'ci' not described in 'ci_hdrc_gadget_destroy'
drivers/usb/chipidea/udc.c:2144: warning: Function parameter or member 'ci' not described in 'ci_hdrc_gadget_init'
Cc: Peter Chen <Peter.Chen@nxp.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200703174148.2749969-13-lee.jones@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Looks like a very popular argument to omit descriptions for.
Fixes the following W=1 kernel build warning(s):
drivers/usb/chipidea/udc.c:80: warning: Function parameter or member 'ci' not described in 'hw_device_state'
drivers/usb/chipidea/udc.c💯 warning: Function parameter or member 'ci' not described in 'hw_ep_flush'
drivers/usb/chipidea/udc.c:121: warning: Function parameter or member 'ci' not described in 'hw_ep_disable'
drivers/usb/chipidea/udc.c:136: warning: Function parameter or member 'ci' not described in 'hw_ep_enable'
drivers/usb/chipidea/udc.c:170: warning: Function parameter or member 'ci' not described in 'hw_ep_get_halt'
drivers/usb/chipidea/udc.c:185: warning: Function parameter or member 'ci' not described in 'hw_ep_prime'
drivers/usb/chipidea/udc.c:215: warning: Function parameter or member 'ci' not described in 'hw_ep_set_halt'
drivers/usb/chipidea/udc.c:238: warning: Function parameter or member 'ci' not described in 'hw_port_is_high_speed'
drivers/usb/chipidea/udc.c:251: warning: Function parameter or member 'ci' not described in 'hw_test_and_clear_complete'
drivers/usb/chipidea/udc.c:263: warning: Function parameter or member 'ci' not described in 'hw_test_and_clear_intr_active'
drivers/usb/chipidea/udc.c:277: warning: Function parameter or member 'ci' not described in 'hw_test_and_clear_setup_guard'
drivers/usb/chipidea/udc.c:288: warning: Function parameter or member 'ci' not described in 'hw_test_and_set_setup_guard'
drivers/usb/chipidea/udc.c:300: warning: Function parameter or member 'ci' not described in 'hw_usb_set_address'
drivers/usb/chipidea/udc.c:312: warning: Function parameter or member 'ci' not described in 'hw_usb_reset'
Cc: Peter Chen <Peter.Chen@nxp.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200703174148.2749969-12-lee.jones@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
No attempt has been made to document any of the demoted functions here.
Fixes the following W=1 kernel build warning(s):
drivers/usb/chipidea/debug.c:25: warning: Function parameter or member 's' not described in 'ci_device_show'
drivers/usb/chipidea/debug.c:25: warning: Function parameter or member 'data' not described in 'ci_device_show'
drivers/usb/chipidea/debug.c:54: warning: Function parameter or member 's' not described in 'ci_port_test_show'
drivers/usb/chipidea/debug.c:54: warning: Function parameter or member 'data' not described in 'ci_port_test_show'
drivers/usb/chipidea/debug.c:75: warning: Function parameter or member 'file' not described in 'ci_port_test_write'
drivers/usb/chipidea/debug.c:75: warning: Function parameter or member 'ubuf' not described in 'ci_port_test_write'
drivers/usb/chipidea/debug.c:75: warning: Function parameter or member 'count' not described in 'ci_port_test_write'
drivers/usb/chipidea/debug.c:75: warning: Function parameter or member 'ppos' not described in 'ci_port_test_write'
drivers/usb/chipidea/debug.c:122: warning: Function parameter or member 's' not described in 'ci_qheads_show'
drivers/usb/chipidea/debug.c:122: warning: Function parameter or member 'data' not described in 'ci_qheads_show'
drivers/usb/chipidea/debug.c:154: warning: Function parameter or member 's' not described in 'ci_requests_show'
drivers/usb/chipidea/debug.c:154: warning: Function parameter or member 'data' not described in 'ci_requests_show'
Cc: Peter Chen <Peter.Chen@nxp.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200703174148.2749969-11-lee.jones@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Firstly we add some missing descriptions. Then we fix some formatting
issues. Kerneldoc expects arguments to be in the format '@.*: '. If
either the '@' or ':' is omitted, kerneldoc gets confused.
Fixes the following W=1 kernel build warning(s):
drivers/usb/chipidea/otg.c:29: warning: Function parameter or member 'ci' not described in 'hw_read_otgsc'
drivers/usb/chipidea/otg.c:82: warning: Function parameter or member 'ci' not described in 'hw_write_otgsc'
drivers/usb/chipidea/otg.c:235: warning: Function parameter or member 'ci' not described in 'ci_hdrc_otg_init'
drivers/usb/chipidea/otg.c:254: warning: Function parameter or member 'ci' not described in 'ci_hdrc_otg_destroy'
Cc: Peter Chen <Peter.Chen@nxp.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200703174148.2749969-10-lee.jones@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Firstly, file headers should not be in kerneldoc format. Function
args should be in the format '@.*: '. We also take the time to
add some descriptions for various argument which have been
previously left out. Finally we remove descriptions for absent
arguments.
Fixes the following W=1 kernel build warning(s):
drivers/usb/gadget/udc/core.c:25: warning: Incorrect use of kernel-doc format: * struct usb_udc - describes one usb device controller
drivers/usb/gadget/udc/core.c:36: warning: cannot understand function prototype: 'struct usb_udc '
drivers/usb/gadget/udc/core.c:901: warning: Function parameter or member 'ep' not described in 'usb_gadget_giveback_request'
drivers/usb/gadget/udc/core.c:901: warning: Function parameter or member 'req' not described in 'usb_gadget_giveback_request'
drivers/usb/gadget/udc/core.c:1098: warning: Function parameter or member 'udc' not described in 'usb_gadget_udc_stop'
drivers/usb/gadget/udc/core.c:1098: warning: Excess function parameter 'gadget' description in 'usb_gadget_udc_stop'
drivers/usb/gadget/udc/core.c:1098: warning: Excess function parameter 'driver' description in 'usb_gadget_udc_stop'
Cc: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200703174148.2749969-9-lee.jones@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixes the following W=1 kernel build warning(s):
drivers/usb/chipidea/core.c:163: warning: Function parameter or member 'ci' not described in 'hw_port_test_set'
Cc: Peter Chen <Peter.Chen@nxp.com>
Cc: David Lopo <dlopo@chipidea.mips.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200703174148.2749969-8-lee.jones@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
No attempt has been made to document any of the functions here.
Fixes the following W=1 kernel build warning(s):
drivers/usb/misc/adutux.c:117: warning: Function parameter or member 'dev' not described in 'adu_abort_transfers'
drivers/usb/misc/adutux.c:653: warning: Function parameter or member 'interface' not described in 'adu_probe'
drivers/usb/misc/adutux.c:653: warning: Function parameter or member 'id' not described in 'adu_probe'
drivers/usb/misc/adutux.c:762: warning: Function parameter or member 'interface' not described in 'adu_disconnect'
Cc: Johan Hovold <johan@kernel.org>
Cc: David Glance <davidgsf@sourceforge.net>
Cc: Juergen Stuber <stuber@loria.fr>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200703174148.2749969-7-lee.jones@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
No attempt has been made to document any of the functions here.
Fixes the following W=1 kernel build warning(s):
drivers/usb/atm/ueagle-atm.c:578: warning: Function parameter or member 'usb' not described in 'uea_send_modem_cmd'
drivers/usb/atm/ueagle-atm.c:578: warning: Function parameter or member 'addr' not described in 'uea_send_modem_cmd'
drivers/usb/atm/ueagle-atm.c:578: warning: Function parameter or member 'size' not described in 'uea_send_modem_cmd'
drivers/usb/atm/ueagle-atm.c:578: warning: Function parameter or member 'buff' not described in 'uea_send_modem_cmd'
drivers/usb/atm/ueagle-atm.c:679: warning: Function parameter or member 'usb' not described in 'uea_load_firmware'
drivers/usb/atm/ueagle-atm.c:679: warning: Function parameter or member 'ver' not described in 'uea_load_firmware'
Cc: Matthieu CASTET <castet.matthieu@free.fr>
Cc: Stanislaw Gruszka <stf_xl@wp.pl>
Cc: Damien Bergamini <damien.bergamini@free.fr>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200703174148.2749969-6-lee.jones@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
No attempt has been made to document any of the functions here.
Fixes the following W=1 kernel build warning(s):
drivers/usb/core/ledtrig-usbport.c:42: warning: Function parameter or member 'usbport_data' not described in 'usbport_trig_usb_dev_observed'
drivers/usb/core/ledtrig-usbport.c:42: warning: Function parameter or member 'usb_dev' not described in 'usbport_trig_usb_dev_observed'
drivers/usb/core/ledtrig-usbport.c:71: warning: Function parameter or member 'usbport_data' not described in 'usbport_trig_update_count'
drivers/usb/core/ledtrig-usbport.c:131: warning: Function parameter or member 'usbport_data' not described in 'usbport_trig_port_observed'
drivers/usb/core/ledtrig-usbport.c:131: warning: Function parameter or member 'usb_dev' not described in 'usbport_trig_port_observed'
drivers/usb/core/ledtrig-usbport.c:131: warning: Function parameter or member 'port1' not described in 'usbport_trig_port_observed'
Cc: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200703174148.2749969-4-lee.jones@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
No attempt has been made to document the function here.
Fixes the following W=1 kernel build warning(s):
drivers/usb/host/ohci-s3c2410.c:356: warning: Function parameter or member 'dev' not described in 'ohci_hcd_s3c2410_probe'
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Kukjin Kim <kgene@kernel.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Roman Weissgaerber <weissg@vienna.at>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Christopher Hoover <ch@hpl.hp.com>
Cc: Ben Dooks <ben@simtec.co.uk>
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200703174148.2749969-3-lee.jones@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Without it, the build system complains that it was declared inside
the parameter list.
Fixes the following W=1 kernel build warning(s):
In file included from drivers/usb/mtu3/mtu3_trace.c:11:
drivers/usb/mtu3/mtu3_debug.h:29:36: warning: ‘struct ssusb_mtk’ declared inside parameter list will not be visible outside of this definition or declaration
29 | void ssusb_dev_debugfs_init(struct ssusb_mtk *ssusb);
| ^~~~~~~~~
drivers/usb/mtu3/mtu3_debug.h:30:35: warning: ‘struct ssusb_mtk’ declared inside parameter list will not be visible outside of this definition or declaration
30 | void ssusb_dr_debugfs_init(struct ssusb_mtk *ssusb);
| ^~~~~~~~~
drivers/usb/mtu3/mtu3_debug.h:31:39: warning: ‘struct ssusb_mtk’ declared inside parameter list will not be visible outside of this definition or declaration
31 | void ssusb_debugfs_create_root(struct ssusb_mtk *ssusb);
| ^~~~~~~~~
drivers/usb/mtu3/mtu3_debug.h:32:39: warning: ‘struct ssusb_mtk’ declared inside parameter list will not be visible outside of this definition or declaration
32 | void ssusb_debugfs_remove_root(struct ssusb_mtk *ssusb);
| ^~~~~~~~~
Cc: Chunfeng Yun <chunfeng.yun@mediatek.com>
Cc: linux-mediatek@lists.infradead.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200703174148.2749969-2-lee.jones@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The EHCI OMAP driver includes <linux/gpio.h> but does not use
any symbols from this file, so drop it.
Cc: Roger Quadros <rogerq@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20200703131059.515436-1-linus.walleij@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Issue:
When PEC is enabled, binding adm1272 to the adm1275 would
fail due to PEC error. See below:
adm1275: probe of xxxx failed with error -74
Diagnosis:
Per the datasheet of adm1272, adm1278, adm1293 and amd1294,
PMON_CONFIG (0xd4) is 16bits wide. On the other hand,
PMON_CONFIG (0xd4) for adm1275 is 8bits wide. The driver should not
assume everything is 8bits wide and read only 8bits from it.
Solution:
If it is adm1272, adm1278, adm1293 and adm1294, use i2c_read_word.
Else, use i2c_read_byte
Testing:
Binding adm1272 to the driver.
The change is only tested on adm1272.
Signed-off-by: Chu Lin <linchuyuan@google.com>
Link: https://lore.kernel.org/r/20200709040612.3977094-1-linchuyuan@google.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Commit f7b93d4294 ("arm64/alternatives: use subsections for replacement
sequences") moved the alternatives replacement sequences into subsections,
in order to keep the as close as possible to the code that they replace.
Unfortunately, this broke the logic in branch_insn_requires_update,
which assumed that any branch into kernel executable code was a branch
that required updating, which is no longer the case now that the code
sequences that are patched in are in the same section as the patch site
itself.
So the only way to discriminate branches that require updating and ones
that don't is to check whether the branch targets the replacement sequence
itself, and so we can drop the call to kernel_text_address() entirely.
Fixes: f7b93d4294 ("arm64/alternatives: use subsections for replacement sequences")
Reported-by: Alexandru Elisei <alexandru.elisei@arm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Alexandru Elisei <alexandru.elisei@arm.com>
Link: https://lore.kernel.org/r/20200709125953.30918-1-ardb@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Some platforms apply the FBC w/as in .init_clock_gating(), some
in fbc_activate(). Move them all to .init_clock_gating() for
consistentce. Also safer since we don't have to worry about the
RMWs clashing with any other runtime use of the same registers.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200708131223.9519-1-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
.get_modes() is supposed to return the number of modes added to the
probed_modes list (not that anyone actually checks for anything
except zero vs. not zero). Let's do that. Also switch over to using
intel_connector_update_modes() instead of hand rolling it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-8-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
With SDVO the pipe config pixel_multiplier only concerns itself with the
data on the SDVO bus. Any HDMI specific pixel repeat must be handled by
the SDVO device itself. To do that simply configure the SDVO pixel
replication factor appropriately. We already set up the infoframe PRB
values correctly via the infoframe helpers.
There is no cap we can check for this. The spec says that 1X,2X,4X are
mandatory, anything else is optional. 1X and 2X are all we need so
we should be able to assume they work.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-7-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
The code assumes that DRM_MODE_FLAG_DBLCLK means that we enable the
pixel repeat feature. That only works with HDMI since it requires
AVI infoframe to signal the information to the sink. Hence even if
the mode dotclock would be valid we cannot currently assume that
we can just ignore the DBLCLK flag. Reject it for DVI sinks.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-6-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
The SDVO/HDMI port register limited color range bit can only be used
with TMDS encoding and not SDVO encoding, ie. to be used only when
using the port as a HDMI port as opposed to a SDVO port. The SDVO
spec does have a note that some GMCHs might allow that, but gen4
bspec vehemently disagrees. I suppose on ILK+ it might work since
the color range handling is on the CPU side rather than on the PCH
side, so there is no clear linkage between the TMDS vs. SDVO
encoding and color range. Alas, I have no hardware to test that
theory.
To implement limited color range support for SDVO->HDMI we need to
ask the SDVO device to do the range compression. Do so, but first
check if the device even supports the colorimetry selection.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-5-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
If the pmd is soft dirty we must mark the pte as soft dirty (and not dirty).
This fixes some cases for guest migration with huge page backings.
Cc: <stable@vger.kernel.org> # 4.8
Fixes: bc29b7ac1d ("s390/mm: clean up pte/pmd encoding")
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
After commit 333cff6c96 ("powercap/drivers/idle_inject: Specify
idle state max latency"), we convert to use play_idle_precise() with
max allowed latency to specify the idle state.
Some function comments still use play_idle(), let's update it to
play_idle_precise().
Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
Signed-off-by: Frank Lee <frank@allwinnertech.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The genpd infrastructure uses the terms master/slave, but such uses have
no external exposures (not even in Documentation/driver-api/pm/*) and are
not mandated by nor associated with any external specifications. Change
the language used through-out to parent/child.
There was one possible exception in the debugfs node
"pm_genpd/pm_genpd_summary" but its path has no hits outside of the
kernel itself when performing a code search[1], and it seems even this
single usage has been non-functional since it was introduced due to a
typo in the Python ("apend" instead of correct "append"). Fix the typo
while we're at it.
Link: https://codesearch.debian.net/ # [1]
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Of the two versions of GHASH that the ARM driver implements, only one
performs aggregation, and so the other one has no use for the powers
of H to be precomputed, or space to be allocated for them in the key
struct. So make the context size dependent on which version is being
selected, and while at it, use a static key to carry this decision,
and get rid of the function pointer.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Introduce an inline wrapper for ghash_do_update() that incorporates
the indirect call to the asm routine that is passed as an argument,
and keep the non-SIMD fallback code out of line. This ensures that
all references to the function pointer are inlined where the address
is taken, removing the need for any indirect calls to begin with.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Now that the ghash and gcm drivers are split, we no longer need to allocate
a key struct for the former that carries powers of H that are only used by
the latter. Also, take this opportunity to clean up the code a little bit.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The remaining ghash implementation does not support aggregation, and so
there is no point in including the precomputed powers of H in the key
struct. So move that into the GCM setkey routine, and get rid of the
shared sub-routine entirely.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
There are two ways to implement SIMD accelerated GCM on arm64:
- using the PMULL instructions for carryless 64x64->128 multiplication,
in which case the architecture guarantees that the AES instructions are
available as well, and so we can use the AEAD implementation that combines
both,
- using the PMULL instructions for carryless 8x8->16 bit multiplication,
which is implemented as a shash, and can be combined with any ctr(aes)
implementation by the generic GCM AEAD template driver.
So let's drop the 64x64->128 shash driver, which is never needed for GCM,
and not suitable for use anywhere else.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
read/write_cr2() go throuh the paravirt XXL indirection, but nested VMX in
a XEN_PV guest is not supported.
Use the native variants.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Message-Id: <20200708195322.344731916@linutronix.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
On guest exit MSR_GS_BASE contains whatever the guest wrote to it and the
first action after returning from the ASM code is to set it to the host
kernel value. This uses wrmsrl() which is interesting at least.
wrmsrl() is either using native_write_msr() or the paravirt variant. The
XEN_PV code is uninteresting as nested SVM in a XEN_PV guest does not work.
But native_write_msr() can be placed out of line by the compiler especially
when paravirtualization is enabled in the kernel configuration. The
function is marked notrace, but still can be probed if
CONFIG_KPROBE_EVENTS_ON_NOTRACE is enabled.
That would be a fatal problem as kprobe events use per-CPU variables which
are GS based and would be accessed with the guest GS. Depending on the GS
value this would either explode in colorful ways or lead to completely
undebugable data corruption.
Aside of that native_write_msr() contains a tracepoint which objtool
complains about as it is invoked from the noinstr section.
As this cannot run inside a XEN_PV guest there is no point in using
wrmsrl(). Use native_wrmsrl() instead which is just a plain native WRMSR
without tracing or anything else attached.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Juergen Gross <jgross@suse.com>
Message-Id: <20200708195322.244847377@linutronix.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Move the functions which are inside the RCU off region into the
non-instrumentable text section.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200708195322.144607767@linutronix.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Move the functions which are inside the RCU off region into the
non-instrumentable text section.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200708195322.037311579@linutronix.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Entering guest mode is more or less the same as returning to user
space. From an instrumentation point of view both leave kernel mode and the
transition to guest or user mode reenables interrupts on the host. In user
mode an interrupt is served directly and in guest mode it causes a VM exit
which then handles or reinjects the interrupt.
The transition from guest mode or user mode to kernel mode disables
interrupts, which needs to be recorded in instrumentation to set the
correct state again.
This is important for e.g. latency analysis because otherwise the execution
time in guest or user mode would be wrongly accounted as interrupt disabled
and could trigger false positives.
Add hardirq tracing to guest enter/exit functions in the same way as it
is done in the user mode enter/exit code, respecting the RCU requirements.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200708195321.934715094@linutronix.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Entering guest mode is more or less the same as returning to user
space. From an instrumentation point of view both leave kernel mode and the
transition to guest or user mode reenables interrupts on the host. In user
mode an interrupt is served directly and in guest mode it causes a VM exit
which then handles or reinjects the interrupt.
The transition from guest mode or user mode to kernel mode disables
interrupts, which needs to be recorded in instrumentation to set the
correct state again.
This is important for e.g. latency analysis because otherwise the execution
time in guest or user mode would be wrongly accounted as interrupt disabled
and could trigger false positives.
Add hardirq tracing to guest enter/exit functions in the same way as it
is done in the user mode enter/exit code, respecting the RCU requirements.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200708195321.822002354@linutronix.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Context tracking for KVM happens way too early in the vcpu_run()
code. Anything after guest_enter_irqoff() and before guest_exit_irqoff()
cannot use RCU and should also be not instrumented.
The current way of doing this covers way too much code. Move it closer to
the actual vmenter/exit code.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200708195321.724574345@linutronix.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
To avoid complex and in some cases incorrect logic in
kvm_spec_ctrl_test_value, just try the guest's given value on the host
processor instead, and if it doesn't #GP, allow the guest to set it.
One such case is when host CPU supports STIBP mitigation
but doesn't support IBRS (as is the case with some Zen2 AMD cpus),
and in this case we were giving guest #GP when it tried to use STIBP
The reason why can can do the host test is that IA32_SPEC_CTRL msr is
passed to the guest, after the guest sets it to a non zero value
for the first time (due to performance reasons),
and as as result of this, it is pointless to emulate #GP condition on
this first access, in a different way than what the host CPU does.
This is based on a patch from Sean Christopherson, who suggested this idea.
Fixes: 6441fa6178 ("KVM: x86: avoid incorrect writes to host MSR_IA32_SPEC_CTRL")
Cc: stable@vger.kernel.org
Suggested-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20200708115731.180097-1-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In guest protected mode, if the current privilege level
is not 0 and the PCE flag in the CR4 register is cleared,
we will inject a #GP for RDPMC usage.
Signed-off-by: Like Xu <like.xu@linux.intel.com>
Message-Id: <20200708074409.39028-1-like.xu@linux.intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
OVMF booted guest running on shadow pages crashes on TRIPLE FAULT after
enabling paging from SMM. The crash is triggered from mmu_check_root() and
is caused by kvm_is_visible_gfn() searching through memslots with as_id = 0
while vCPU may be in a different context (address space).
Introduce kvm_vcpu_is_visible_gfn() and use it from mmu_check_root().
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20200708140023.1476020-1-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Lee Jones