Add support from RPMH regulators found in SDX55 platform
Signed-off-by: NVinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20201126093018.1085594-2-vkoul@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Selectors lower than linear_min_sel should not be considered invalid.
Thus return zero in case _regulator_list_voltage(),
regulator_list_hardware_vsel() or regulator_list_voltage_table()
receives such selectors as argument.

Fixes: bdcd1177 ("regulator: core: validate selector against linear_min_sel")
Reported-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NClaudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/1606325147-606-1-git-send-email-claudiu.beznea@microchip.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add a simple regulator based on SCMI Voltage Domain Protocol.
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
----
v6 --> v7
- add proper blank lines between semantic blocks
- fix return value on error path of scmi_reg_is_enabled()
- use generic Failure message on err path of info_get()
- fix comment containing apostrophe

v3 --> v4
- using of_match_full_name core regulator flag
- avoid coccinelle falde complaints about pointer-sized allocations

v2 --> v3
- remove multiple linear mappings support
- removed duplicated voltage name printout
- added a few comments
- simplified return path in scmi_reg_set_voltage_sel()

v1 --> v2
- removed duplicate regulator naming
- removed redundant .get/set_voltage ops: only _sel variants implemented
- removed condexpr on fail path to increase readability

v0 --> v1
- fixed init_data constraint parsing
- fixes for v5.8 (linear_range.h)
- fixed commit message content and subject line format
- factored out SCMI core specific changes to distinct patch
- reworked Kconfig and Makefile to keep proper alphabetic order
- fixed SPDX comment style
- removed unneeded inline functions
- reworked conditionals for legibility
- fixed some return paths to properly report SCMI original errors codes
- added some more descriptive error messages when fw returns invalid ranges
- removed unneeded explicit devm_regulator_unregister from .remove()
Link: https://lore.kernel.org/r/20201123202336.46701-4-cristian.marussi@arm.comSigned-off-by: NMark Brown <broonie@kernel.org>

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a fallthrough pseudo-keyword instead of letting the
code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/c0efb81064f71837f19408f65b52d155103ee514.1605896059.git.gustavoars@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

During regulators registration, if .of_match and .regulators_node are
defined as non-null strings in struct regulator_desc the core searches the
DT subtree rooted at .regulators_node trying to match, at first, .of_match
against the 'regulator-compatible' property and, then, falling back to use
the name of the node itself to determine a good match.

Property 'regulator-compatible', though, is now deprecated and falling back
to match against the node name, works fine only as long as the involved
nodes are named in an unique way across the searched subtree; if that's not
the case, like when using <common-name>@<unit> style naming for properties
indexed via 'reg' property (as advised by the standard), the above matching
mechanism based on the simple common name will lead to multiple matches and
the only viable alternative would be to properly define the now deprecated
'regulator-compatible' as the node full name, i.e. <common-name>@<unit>.

In order to address this case without using such deprecated binding, define
a new boolean flag .of_match_full_name in struct regulator_desc to force
the core to match against the node full-name instead of the plain name.
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20201119191051.46363-4-cristian.marussi@arm.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add SCMI voltage domain device name to the core list of supported protocol
devices so that it can be enumerated if the firmware supports it.

Link: https://lore.kernel.org/r/20201119191051.46363-3-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

SCMI v3.0 introduces voltage domain protocol which provides commands to:
 - Discover the voltage levels supported by a domain
 - Get the configuration and voltage level of a domain
 - Set the configuration and voltage level of a domain

Let us add support for the same.

Link: https://lore.kernel.org/r/20201119191051.46363-2-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Do not continue if selector has already been located.
Signed-off-by: NClaudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/1605290164-11556-1-git-send-email-claudiu.beznea@microchip.comSigned-off-by: NMark Brown <broonie@kernel.org>

There are regulators who's min selector is not zero. Selectors loops
(looping b/w zero and regulator::desc::n_voltages) might throw errors
because invalid selectors are used (lower than
regulator::desc::linear_min_sel). For this situations validate selectors
against regulator::desc::linear_min_sel.
Signed-off-by: NClaudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/1605280870-32432-2-git-send-email-claudiu.beznea@microchip.comSigned-off-by: NMark Brown <broonie@kernel.org>

struct mcp16502 has no members called rdev or rmap. Remove the
documentation.
Signed-off-by: NClaudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/1605280870-32432-7-git-send-email-claudiu.beznea@microchip.comSigned-off-by: NMark Brown <broonie@kernel.org>

MCP16502 have configurable ramp delay support (via DVSR bits in
regulators' CFG register).
Signed-off-by: NClaudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/1605280870-32432-6-git-send-email-claudiu.beznea@microchip.comSigned-off-by: NMark Brown <broonie@kernel.org>

MCP16502 have multiple registers for each regulator (as described
in enum mcp16502_reg). Adapt the code to be able to get/set all these
registers. This is necessary for the following commits.
Signed-off-by: NClaudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/1605280870-32432-5-git-send-email-claudiu.beznea@microchip.comSigned-off-by: NMark Brown <broonie@kernel.org>

Selectors b/w zero and VDD_LOW_SEL are not valid. Use linear_min_sel.

Fixes: 919261c0 ("regulator: mcp16502: add regulator driver for MCP16502")
Signed-off-by: NClaudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/1605280870-32432-4-git-send-email-claudiu.beznea@microchip.comSigned-off-by: NMark Brown <broonie@kernel.org>

Help debugging the case when set_machine_constraints() needs to be
repeated.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # stpmic1
Link: https://lore.kernel.org/r/f9cba575580369e46661a9278ee6c6a8d8564c2a.1605226675.git.mirq-linux@rere.qmqm.plSigned-off-by: NMark Brown <broonie@kernel.org>

Setups where regulator (especially the buck8) output voltage is scaled
by adding external connection where some other regulator output is
connected to feedback-pin (over suitable resistors) is getting popular
amongst users of BD71837. This allows for example scaling down the
buck8 voltages to suit lover GPU voltages for projects where buck8 is
(ab)used to supply power for GPU. As a note - some setups do allow DVS
for buck8. This do produce voltage spikes and the HW must be evaluated
to be able to survive them. Thus this commit still keep the DVS disabled
for non DVS bucks by default. Let's not help you burn your proto board.

Allow describing this external connection from DT and scale the
voltages accordingly. This is what the connection should look like:

|------------|
|    buck 8  |-------+----->Vout
|            |       |
|------------|       |
     | FB pin        |
     |               |
     +-------+--R2---+
             |
             R1
             |
     V FB-pull-up

     Here the buck output is sifted according to formula:

Vout_o = Vo - (Vpu - Vo)*R2/R1
Linear_step = step_orig*(R1+R2)/R1

where:
Vout_o is adjusted voltage output at vsel reg value 0
Vo is original voltage output at vsel reg value 0
Vpu is the pull-up voltage V FB-pull-up in the picture
R1 and R2 are resistor values.

Bring support for specifying the Vpu, R1 and R2 from device tree and
scale voltages if they are given.
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/89b2be87074f307a8823f15f34e1f662023cbf36.1604994184.git.matti.vaittinen@fi.rohmeurope.comSigned-off-by: NMark Brown <broonie@kernel.org>

In regulator_late_cleanup when is_enabled failed, don't try to disable
the regulator since it would likely to fail too and causing confusing
error messages.
Signed-off-by: NPi-Hsun Shih <pihsun@chromium.org>
Link: https://lore.kernel.org/r/20201106064817.3290927-1-pihsun@chromium.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Add support for the Dialog Semiconductor DA9121, a single-channel
dual-phase buck converter controlled via I2C.
Signed-off-by: NVincent Whitchurch <vincent.whitchurch@axis.com>
Link: https://lore.kernel.org/r/20201103100021.19603-3-vincent.whitchurch@axis.comSigned-off-by: NMark Brown <broonie@kernel.org>

regulator_get_voltage_rdev() is called in regulator probe() when
applying machine constraints.  The "fixed" commit exposed the problem
that non-bypassed regulators can forward the request to its parent
(like bypassed ones) supply. Return -EPROBE_DEFER when the supply
is expected but not resolved yet.

Fixes: aea6cb99 ("regulator: resolve supply after creating regulator")
Cc: stable@vger.kernel.org
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Reported-by: NOndřej Jirman <megous@megous.com>
Reported-by: NCorentin Labbe <clabbe.montjoie@gmail.com>
Tested-by: NOndřej Jirman <megous@megous.com>
Link: https://lore.kernel.org/r/a9041d68b4d35e4a2dd71629c8a6422662acb5ee.1604351936.git.mirq-linux@rere.qmqm.plSigned-off-by: NMark Brown <broonie@kernel.org>

There is a regular need in the kernel to provide a way to declare having a
dynamically sized set of trailing elements in a structure. Kernel code should
always use “flexible array members”[1] for these cases. The older style of
one-element or zero-length arrays should no longer be used[2].

[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arraysSigned-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>

There is a regular need in the kernel to provide a way to declare having a
dynamically sized set of trailing elements in a structure.  Kernel code
should always use “flexible array members”[1] for these cases.  The
older style of one-element or zero-length arrays should no longer be
used[2].

Refactor the code according to the use of a flexible-array member in
struct gve_stats_report, instead of a zero-length array, and use the
struct_size() helper to calculate the size for the resource allocation.

[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arraysSigned-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>

There is a regular need in the kernel to provide a way to declare having a
dynamically sized set of trailing elements in a structure. Kernel code should
always use “flexible array members”[1] for these cases. The older style of
one-element or zero-length arrays should no longer be used[2].

[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arraysSigned-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>

Add macaddr parameter to the module to set the MAC address to use
Signed-off-by: NLaurent Vivier <lvivier@redhat.com>
Link: https://lore.kernel.org/r/20201029122050.776445-3-lvivier@redhat.comSigned-off-by: NMichael S. Tsirkin <mst@redhat.com>
Acked-by: NJason Wang <jasowang@redhat.com>

vdpa_sim generates a ramdom MAC address but it is never used by upper
layers because the VIRTIO_NET_F_MAC bit is not set in the features list.

Because of that, virtio-net always regenerates a random MAC address each
time it is loaded whereas the address should only change on vdpa_sim
load/unload.

Fix that by adding VIRTIO_NET_F_MAC in the features list of vdpa_sim.

Fixes: 2c53d0f6 ("vdpasim: vDPA device simulator")
Cc: jasowang@redhat.com
Signed-off-by: NLaurent Vivier <lvivier@redhat.com>
Link: https://lore.kernel.org/r/20201029122050.776445-2-lvivier@redhat.comSigned-off-by: NMichael S. Tsirkin <mst@redhat.com>
Acked-by: NJason Wang <jasowang@redhat.com>

LKP considered variable 'ret' in vhost_vdpa_setup_vq_irq() as
a unused variable, so suggest we remove it. Actually it stores
return value of irq_bypass_register_producer(), but we did not
check it, we should handle the failure case.

This commit will print a message if irq bypass register producer
fail, in this case, vqs still remain functional.
Signed-off-by: NZhu Lingshan <lingshan.zhu@intel.com>
Reported-by: Nkernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/20201023104046.404794-1-lingshan.zhu@intel.comSigned-off-by: NMichael S. Tsirkin <mst@redhat.com>
Acked-by: NJason Wang <jasowang@redhat.com>

Since commit f959dcd6
("dma-direct: Fix potential NULL pointer dereference")
an error is reported when we load vdpa_sim and virtio-vdpa:

[  129.351207] net eth0: Unexpected TXQ (0) queue failure: -12

It seems that dma_mask is not initialized.

This patch initializes dma_mask() and calls dma_set_mask_and_coherent()
to fix the problem.

Full log:

[  128.548628] ------------[ cut here ]------------
[  128.553268] WARNING: CPU: 23 PID: 1105 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x14c/0x1d0
[  128.562139] Modules linked in: virtio_net net_failover failover virtio_vdpa vdpa_sim vringh vhost_iotlb vdpa xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink tun bridge stp llc iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi rfkill intel_rapl_msr intel_rapl_common isst_if_common sunrpc skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ipmi_ssif kvm mgag200 i2c_algo_bit irqbypass drm_kms_helper crct10dif_pclmul crc32_pclmul syscopyarea ghash_clmulni_intel iTCO_wdt sysfillrect iTCO_vendor_support sysimgblt rapl fb_sys_fops dcdbas intel_cstate drm acpi_ipmi ipmi_si mei_me dell_smbios intel_uncore ipmi_devintf mei i2c_i801 dell_wmi_descriptor wmi_bmof pcspkr lpc_ich i2c_smbus ipmi_msghandler acpi_power_meter ip_tables xfs libcrc32c sd_mod t10_pi sg ahci libahci libata megaraid_sas tg3 crc32c_intel wmi dm_mirror dm_region_hash dm_log
[  128.562188]  dm_mod
[  128.651334] CPU: 23 PID: 1105 Comm: NetworkManager Tainted: G S        I       5.10.0-rc1+ #59
[  128.659939] Hardware name: Dell Inc. PowerEdge R440/04JN2K, BIOS 2.8.1 06/30/2020
[  128.667419] RIP: 0010:dma_map_page_attrs+0x14c/0x1d0
[  128.672384] Code: 1c 25 28 00 00 00 0f 85 97 00 00 00 48 83 c4 10 5b 5d 41 5c 41 5d c3 4c 89 da eb d7 48 89 f2 48 2b 50 18 48 89 d0 eb 8d 0f 0b <0f> 0b 48 c7 c0 ff ff ff ff eb c3 48 89 d9 48 8b 40 40 e8 2d a0 aa
[  128.691131] RSP: 0018:ffffae0f0151f3c8 EFLAGS: 00010246
[  128.696357] RAX: ffffffffc06b7400 RBX: 00000000000005fa RCX: 0000000000000000
[  128.703488] RDX: 0000000000000040 RSI: ffffcee3c7861200 RDI: ffff9e2bc16cd000
[  128.710620] RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000000
[  128.717754] R10: 0000000000000002 R11: 0000000000000000 R12: ffff9e472cb291f8
[  128.724886] R13: ffff9e2bc14da780 R14: ffff9e472bc20000 R15: ffff9e2bc1b14940
[  128.732020] FS:  00007f887bae23c0(0000) GS:ffff9e4ac01c0000(0000) knlGS:0000000000000000
[  128.740105] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  128.745852] CR2: 0000562bc09de998 CR3: 00000003c156c006 CR4: 00000000007706e0
[  128.752982] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  128.760114] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  128.767247] PKRU: 55555554
[  128.769961] Call Trace:
[  128.772418]  virtqueue_add+0x81e/0xb00
[  128.776176]  virtqueue_add_inbuf_ctx+0x26/0x30
[  128.780625]  try_fill_recv+0x3a2/0x6e0 [virtio_net]
[  128.785509]  virtnet_open+0xf9/0x180 [virtio_net]
[  128.790217]  __dev_open+0xe8/0x180
[  128.793620]  __dev_change_flags+0x1a7/0x210
[  128.797808]  dev_change_flags+0x21/0x60
[  128.801646]  do_setlink+0x328/0x10e0
[  128.805227]  ? __nla_validate_parse+0x121/0x180
[  128.809757]  ? __nla_parse+0x21/0x30
[  128.813338]  ? inet6_validate_link_af+0x5c/0xf0
[  128.817871]  ? cpumask_next+0x17/0x20
[  128.821535]  ? __snmp6_fill_stats64.isra.54+0x6b/0x110
[  128.826676]  ? __nla_validate_parse+0x47/0x180
[  128.831120]  __rtnl_newlink+0x541/0x8e0
[  128.834962]  ? __nla_reserve+0x38/0x50
[  128.838713]  ? security_sock_rcv_skb+0x2a/0x40
[  128.843158]  ? netlink_deliver_tap+0x2c/0x1e0
[  128.847518]  ? netlink_attachskb+0x1d8/0x220
[  128.851793]  ? skb_queue_tail+0x1b/0x50
[  128.855641]  ? fib6_clean_node+0x43/0x170
[  128.859652]  ? _cond_resched+0x15/0x30
[  128.863406]  ? kmem_cache_alloc_trace+0x3a3/0x420
[  128.868110]  rtnl_newlink+0x43/0x60
[  128.871602]  rtnetlink_rcv_msg+0x12c/0x380
[  128.875701]  ? rtnl_calcit.isra.39+0x110/0x110
[  128.880147]  netlink_rcv_skb+0x50/0x100
[  128.883987]  netlink_unicast+0x1a5/0x280
[  128.887913]  netlink_sendmsg+0x23d/0x470
[  128.891839]  sock_sendmsg+0x5b/0x60
[  128.895331]  ____sys_sendmsg+0x1ef/0x260
[  128.899255]  ? copy_msghdr_from_user+0x5c/0x90
[  128.903702]  ___sys_sendmsg+0x7c/0xc0
[  128.907369]  ? dev_forward_change+0x130/0x130
[  128.911731]  ? sysctl_head_finish.part.29+0x24/0x40
[  128.916616]  ? new_sync_write+0x11f/0x1b0
[  128.920628]  ? mntput_no_expire+0x47/0x240
[  128.924727]  __sys_sendmsg+0x57/0xa0
[  128.928309]  do_syscall_64+0x33/0x40
[  128.931887]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  128.936937] RIP: 0033:0x7f88792e3857
[  128.940518] Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48
[  128.959263] RSP: 002b:00007ffdca60dea0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e
[  128.966827] RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007f88792e3857
[  128.973960] RDX: 0000000000000000 RSI: 00007ffdca60def0 RDI: 000000000000000c
[  128.981095] RBP: 00007ffdca60def0 R08: 0000000000000000 R09: 0000000000000000
[  128.988224] R10: 0000000000000001 R11: 0000000000000293 R12: 0000000000000000
[  128.995357] R13: 0000000000000000 R14: 00007ffdca60e0a8 R15: 00007ffdca60e09c
[  129.002492] CPU: 23 PID: 1105 Comm: NetworkManager Tainted: G S        I       5.10.0-rc1+ #59
[  129.011093] Hardware name: Dell Inc. PowerEdge R440/04JN2K, BIOS 2.8.1 06/30/2020
[  129.018571] Call Trace:
[  129.021027]  dump_stack+0x57/0x6a
[  129.024346]  __warn.cold.14+0xe/0x3d
[  129.027925]  ? dma_map_page_attrs+0x14c/0x1d0
[  129.032283]  report_bug+0xbd/0xf0
[  129.035602]  handle_bug+0x44/0x80
[  129.038922]  exc_invalid_op+0x13/0x60
[  129.042589]  asm_exc_invalid_op+0x12/0x20
[  129.046602] RIP: 0010:dma_map_page_attrs+0x14c/0x1d0
[  129.051566] Code: 1c 25 28 00 00 00 0f 85 97 00 00 00 48 83 c4 10 5b 5d 41 5c 41 5d c3 4c 89 da eb d7 48 89 f2 48 2b 50 18 48 89 d0 eb 8d 0f 0b <0f> 0b 48 c7 c0 ff ff ff ff eb c3 48 89 d9 48 8b 40 40 e8 2d a0 aa
[  129.070311] RSP: 0018:ffffae0f0151f3c8 EFLAGS: 00010246
[  129.075536] RAX: ffffffffc06b7400 RBX: 00000000000005fa RCX: 0000000000000000
[  129.082669] RDX: 0000000000000040 RSI: ffffcee3c7861200 RDI: ffff9e2bc16cd000
[  129.089803] RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000000
[  129.096936] R10: 0000000000000002 R11: 0000000000000000 R12: ffff9e472cb291f8
[  129.104068] R13: ffff9e2bc14da780 R14: ffff9e472bc20000 R15: ffff9e2bc1b14940
[  129.111200]  virtqueue_add+0x81e/0xb00
[  129.114952]  virtqueue_add_inbuf_ctx+0x26/0x30
[  129.119399]  try_fill_recv+0x3a2/0x6e0 [virtio_net]
[  129.124280]  virtnet_open+0xf9/0x180 [virtio_net]
[  129.128984]  __dev_open+0xe8/0x180
[  129.132390]  __dev_change_flags+0x1a7/0x210
[  129.136575]  dev_change_flags+0x21/0x60
[  129.140415]  do_setlink+0x328/0x10e0
[  129.143994]  ? __nla_validate_parse+0x121/0x180
[  129.148528]  ? __nla_parse+0x21/0x30
[  129.152107]  ? inet6_validate_link_af+0x5c/0xf0
[  129.156639]  ? cpumask_next+0x17/0x20
[  129.160306]  ? __snmp6_fill_stats64.isra.54+0x6b/0x110
[  129.165443]  ? __nla_validate_parse+0x47/0x180
[  129.169890]  __rtnl_newlink+0x541/0x8e0
[  129.173731]  ? __nla_reserve+0x38/0x50
[  129.177483]  ? security_sock_rcv_skb+0x2a/0x40
[  129.181928]  ? netlink_deliver_tap+0x2c/0x1e0
[  129.186286]  ? netlink_attachskb+0x1d8/0x220
[  129.190560]  ? skb_queue_tail+0x1b/0x50
[  129.194401]  ? fib6_clean_node+0x43/0x170
[  129.198411]  ? _cond_resched+0x15/0x30
[  129.202163]  ? kmem_cache_alloc_trace+0x3a3/0x420
[  129.206869]  rtnl_newlink+0x43/0x60
[  129.210361]  rtnetlink_rcv_msg+0x12c/0x380
[  129.214462]  ? rtnl_calcit.isra.39+0x110/0x110
[  129.218908]  netlink_rcv_skb+0x50/0x100
[  129.222747]  netlink_unicast+0x1a5/0x280
[  129.226672]  netlink_sendmsg+0x23d/0x470
[  129.230599]  sock_sendmsg+0x5b/0x60
[  129.234090]  ____sys_sendmsg+0x1ef/0x260
[  129.238015]  ? copy_msghdr_from_user+0x5c/0x90
[  129.242461]  ___sys_sendmsg+0x7c/0xc0
[  129.246128]  ? dev_forward_change+0x130/0x130
[  129.250487]  ? sysctl_head_finish.part.29+0x24/0x40
[  129.255368]  ? new_sync_write+0x11f/0x1b0
[  129.259381]  ? mntput_no_expire+0x47/0x240
[  129.263478]  __sys_sendmsg+0x57/0xa0
[  129.267058]  do_syscall_64+0x33/0x40
[  129.270639]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  129.275689] RIP: 0033:0x7f88792e3857
[  129.279268] Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48
[  129.298015] RSP: 002b:00007ffdca60dea0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e
[  129.305581] RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007f88792e3857
[  129.312712] RDX: 0000000000000000 RSI: 00007ffdca60def0 RDI: 000000000000000c
[  129.319846] RBP: 00007ffdca60def0 R08: 0000000000000000 R09: 0000000000000000
[  129.326978] R10: 0000000000000001 R11: 0000000000000293 R12: 0000000000000000
[  129.334109] R13: 0000000000000000 R14: 00007ffdca60e0a8 R15: 00007ffdca60e09c
[  129.341249] ---[ end trace c551e8028fbaf59d ]---
[  129.351207] net eth0: Unexpected TXQ (0) queue failure: -12
[  129.360445] net eth0: Unexpected TXQ (0) queue failure: -12
[  129.824428] net eth0: Unexpected TXQ (0) queue failure: -12

Fixes: 2c53d0f6 ("vdpasim: vDPA device simulator")
Signed-off-by: NLaurent Vivier <lvivier@redhat.com>
Link: https://lore.kernel.org/r/20201027175914.689278-1-lvivier@redhat.comSigned-off-by: NMichael S. Tsirkin <mst@redhat.com>
Cc: stable@vger.kernel.org
Acked-by: NJason Wang <jasowang@redhat.com>

This reverts commit 7ed9e3d9.

The patch creates a DoS risk since it can result in a high order memory
allocation.

Fixes: 7ed9e3d9 ("vhost-vdpa: fix page pinning leakage in error path")
Cc: stable@vger.kernel.org
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Fix to return the variable "err" from the error handling case instead
of "ret".

Fixes: 94abbccd ("vdpa/mlx5: Add shared memory registration code")
Signed-off-by: NJing Xiangfeng <jingxiangfeng@huawei.com>
Link: https://lore.kernel.org/r/20201026070637.164321-1-jingxiangfeng@huawei.comSigned-off-by: NMichael S. Tsirkin <mst@redhat.com>
Acked-by: NEli Cohen <elic@nvidia.com>
Cc: stable@vger.kernel.org
Acked-by: NJason Wang <jasowang@redhat.com>

The copy_to/from_user() functions return the number of bytes which we
weren't able to copy but the ioctl should return -EFAULT if they fail.

Fixes: a127c5bb ("vhost-vdpa: fix backend feature ioctls")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20201023120853.GI282278@mwandaSigned-off-by: NMichael S. Tsirkin <mst@redhat.com>
Cc: stable@vger.kernel.org
Acked-by: NJason Wang <jasowang@redhat.com>

When the system goes to suspend, if the controller is at device mode with
cable connecting to host, the call stack is: cdns3_suspend->
cdns3_gadget_suspend -> cdns3_disconnect_gadget, after cdns3_disconnect_gadget
is called, it owns lock wrongly, it causes the system being deadlock after
resume due to at cdns3_device_thread_irq_handler, it tries to get the lock,
but can't get it forever.

To fix it, we delete the unlock-lock operations at cdns3_disconnect_gadget,
and do it at the caller.

Fixes: b1234e3b ("usb: cdns3: add runtime PM support")
Acked-by: NPawel Laszczak <pawell@cadence.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>

Patch fixes issue caused setting On-chip memory overflow bit in usb_sts
register. The issue occurred because EP_CFG register was set twice
before USB_STS.CFGSTS was set. Every write operation on EP_CFG.BUFFERING
causes that controller increases internal counter holding the number
of reserved on-chip buffers. First time this register was updated in
function cdns3_ep_config before delegating SET_CONFIGURATION request
to class driver and again it was updated when class wanted to enable
endpoint.  This patch fixes this issue by configuring endpoints
enabled by class driver in cdns3_gadget_ep_enable and others just
before status stage.

Cc: stable@vger.kernel.org#v5.8+
Fixes: 7733f6c3 ("usb: cdns3: Add Cadence USB3 DRD Driver")
Reported-and-tested-by: NPeter Chen <peter.chen@nxp.com>
Signed-off-by: NPawel Laszczak <pawell@cadence.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>

While I thought I had this correct (since it actually did reject modes
like I expected during testing), Ville Syrjala from Intel pointed out
that the logic here isn't correct. max_clock refers to the max data rate
supported by the DP encoder. So, limiting it to the output of ds_clock (which
refers to the maximum dotclock of the downstream DP device) doesn't make any
sense. Additionally, since we're using the connector's bpc as the canonical BPC
we should use this in mode_valid until we support dynamically setting the bpp
based on bandwidth constraints.

https://lists.freedesktop.org/archives/dri-devel/2020-September/280276.html

For more info.

So, let's rewrite this using Ville's advice.

v2:
* Ville pointed out I mixed up the dotclock and the link rate. So fix that...
* ...and also rename all the variables in this function to be more appropriately
  labeled so I stop mixing them up.
* Reuse the bpp from the connector for now until we have dynamic bpp selection.
* Use use DIV_ROUND_UP for calculating the mode rate like i915 does, which we
  should also have been doing from the start
Signed-off-by: NLyude Paul <lyude@redhat.com>
Fixes: 409d3813 ("drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode validation")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Ville also pointed out that I got a lot of the logic here wrong as well, whoops.
While I don't think anyone's likely using 3D output with nouveau, the next patch
will make nouveau_conn_mode_valid() make a lot less sense. So, let's just get
rid of it and open-code it like before, while taking care to move the 3D frame
packing calculations on the dot clock into the right place.
Signed-off-by: NLyude Paul <lyude@redhat.com>
Fixes: d6a9efec ("drm/nouveau/kms/nv50-: Share DP SST mode_valid() handling with MST")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v5.8+
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

With this we try to detect if the endianess switch works and assume LE if
not. Suggested by Ben.

Fixes: 51c05340 ("drm/nouveau/device: detect if changing endianness failed")
Signed-off-by: NKarol Herbst <kherbst@redhat.com>
Cc: <stable@vger.kernel.org> # v5.8+
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

we can't use nouveau_bo_ref here as no ttm object was allocated and
nouveau_bo_ref mainly deals with that. Simply deallocate the object.
Signed-off-by: NKarol Herbst <kherbst@redhat.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Not entirely sure why this never came up when I originally tested this
(maybe some BIOSes already have this setup?) but the ->caps_init vfunc
appears to cause the display engine to throw an exception on driver
init, at least on my ThinkPad P72:

nouveau 0000:01:00.0: disp: chid 0 mthd 008c data 00000000 0000508c 0000102b

This is magic nvidia speak for "You need to have the DMA notifier offset
programmed before you can call NV507D_GET_CAPABILITIES." So, let's fix
this by doing that, and also perform an update afterwards to prevent
racing with the GPU when reading capabilities.

v2:
* Don't just program the DMA notifier offset, make sure to actually
  perform an update
v3:
* Don't call UPDATE()
* Actually read the correct notifier fields, as apparently the
  CAPABILITIES_DONE field lives in a different location than the main
  NV_DISP_CORE_NOTIFIER_1 field. As well, 907d+ use a different
  CAPABILITIES_DONE field then pre-907d cards.
v4:
* Don't forget to check the return value of core507d_read_caps()
v5:
* Get rid of NV50_DISP_CAPS_NTFY[14], use NV50_DISP_CORE_NTFY
* Disable notifier after calling GetCapabilities()
Signed-off-by: NLyude Paul <lyude@redhat.com>
Fixes: 4a2cb418 ("drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP interlacing support")
Cc: <stable@vger.kernel.org> # v5.8+
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The user level OpenCL code shouldn't have to align start and end
addresses to a page boundary. That is better handled in the nouveau
driver. The npages field is also redundant since it can be computed
from the start and end addresses.
Signed-off-by: NRalph Campbell <rcampbell@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

There is a regular need in the kernel to provide a way to declare having a
dynamically sized set of trailing elements in a structure. Kernel code should
always use “flexible array members”[1] for these cases. The older style of
one-element or zero-length arrays should no longer be used[2].

[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arraysSigned-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>

There is a regular need in the kernel to provide a way to declare having a
dynamically sized set of trailing elements in a structure. Kernel code should
always use “flexible array members”[1] for these cases. The older style of
one-element or zero-length arrays should no longer be used[2].

[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arraysSigned-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>

K2G devices still only use single parameter for power-domains property,
so check for this properly in the driver. Without this, every peripheral
fails to probe resulting in boot failure.

Link: https://lore.kernel.org/r/20201029093337.21170-1-t-kristo@ti.com
Fixes: efa5c01c ("soc: ti: ti_sci_pm_domains: switch to use multiple genpds instead of one")
Reported-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Acked-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <ssantosh@kernel.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

With LOCKDEP enabled, CTI driver triggers the following splat due
to uninitialized lock class for dynamically allocated attribute
objects.

[    5.372901] coresight etm0: CPU0: ETM v4.0 initialized
[    5.376694] coresight etm1: CPU1: ETM v4.0 initialized
[    5.380785] coresight etm2: CPU2: ETM v4.0 initialized
[    5.385851] coresight etm3: CPU3: ETM v4.0 initialized
[    5.389808] BUG: key ffff00000564a798 has not been registered!
[    5.392456] ------------[ cut here ]------------
[    5.398195] DEBUG_LOCKS_WARN_ON(1)
[    5.398233] WARNING: CPU: 1 PID: 32 at kernel/locking/lockdep.c:4623 lockdep_init_map_waits+0x14c/0x260
[    5.406149] Modules linked in:
[    5.415411] CPU: 1 PID: 32 Comm: kworker/1:1 Not tainted 5.9.0-12034-gbbe85027 #51
[    5.418553] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
[    5.426453] Workqueue: events amba_deferred_retry_func
[    5.433299] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
[    5.438252] pc : lockdep_init_map_waits+0x14c/0x260
[    5.444410] lr : lockdep_init_map_waits+0x14c/0x260
[    5.449007] sp : ffff800012bbb720
...

[    5.531561] Call trace:
[    5.536847]  lockdep_init_map_waits+0x14c/0x260
[    5.539027]  __kernfs_create_file+0xa8/0x1c8
[    5.543539]  sysfs_add_file_mode_ns+0xd0/0x208
[    5.548054]  internal_create_group+0x118/0x3c8
[    5.552307]  internal_create_groups+0x58/0xb8
[    5.556733]  sysfs_create_groups+0x2c/0x38
[    5.561160]  device_add+0x2d8/0x768
[    5.565148]  device_register+0x28/0x38
[    5.568537]  coresight_register+0xf8/0x320
[    5.572358]  cti_probe+0x1b0/0x3f0

...

Fix this by initializing the attributes when they are allocated.

Fixes: 3c5597e3 ("coresight: cti: Add connection information to sysfs")
Reported-by: NLeo Yan <leo.yan@linaro.org>
Tested-by: NLeo Yan <leo.yan@linaro.org>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20201029164559.1268531-2-mathieu.poirier@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>