summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-12-18scsi: powertec: remove the explicit use_clustering settingChristoph Hellwig
This driver already sets the dma_boundary to PAGE_SIZE - 1, which has the same result. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-12-18scsi: cumana_2: remove the explicit use_clustering settingChristoph Hellwig
This driver already sets the dma_boundary to PAGE_SIZE - 1, which has the same result. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-12-18scsi: introduce a max_segment_size host_template parametersChristoph Hellwig
This allows the host driver to indicate the maximum supported segment size in a nice an easy way, so that the driver doesn't have to worry about DMA-layer imposed limitations. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-12-18scsi: flip the default on use_clusteringChristoph Hellwig
Most SCSI drivers want to enable "clustering", that is merging of segments so that they might span more than a single page. Remove the ENABLE_CLUSTERING define, and require drivers to explicitly set DISABLE_CLUSTERING to disable this feature. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-12-18scsi: make sure all drivers set the use_clustering flagChristoph Hellwig
A few drivers were not setting the use_clustering flag at all and thus default to disable. Fix them up to explicitly set this field in preparation for additional cleanups. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-12-18scsi: target/core: Use kmem_cache_free() instead of kfree()Wei Yongjun
memory allocated by kmem_cache_alloc() should be freed using kmem_cache_free(), not kfree(). Fixes: ad669505c4e9 ("scsi: target/core: Make sure that target_wait_for_sess_cmds() waits long enough") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-12-18scsi: virtio_scsi: Remove per-target data because it is no longer usedBart Van Assche
Commit b5b6e8c8d3b4 ("scsi: virtio_scsi: fix IO hang caused by automatic irq vector affinity") removed all virtio_scsi hostdata users. Since the SCSI host data is no longer used, also remove the host data itself. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Ming Lei <ming.lei@redhat.com> Cc: Hannes Reinecke <hare@suse.de> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-12-18RDMA: Cleanup undesired pd->uobject usageShamir Rabinovitch
Drivers should be using udata to determine if a method is invoked from user space or kernel space. A pd does not necessarily say a different objects is kernel or user. Transforming the tests to use udata eliminates a large number of uobject references from the drivers. Signed-off-by: Shamir Rabinovitch <shamir.rabinovitch@oracle.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2018-12-18Merge tag 'mlx5-uplink-rep-2018-12-15' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux Saeed Mahameed: ==================== mlx5-uplink-rep-2018-12-15 Or Gerlitz says: This series is essentially a cleanup to align with the rest of the NIC switchdev drivers and make us more robust and clear/n: currently the PF netdev serves as the mlx5 e-switch uplink netdev representor when going into switchdev mode and back as plain NIC netdev when going out. This causes some irregularities and misc troubles. Move to use dedicated uplink rep, as we have for the VF vports. The uplink rep netdev does has sysfs link and supports the sriov vf mac ndo, these two are in use by libvirt and other orchestrators, It also has richer ethtool support to allow controlling the port link & mtu along with supporting dcb and plugging into the mlx5 lag logic. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2018-12-18Merge branch 'macb-DMA-race-fixes'David S. Miller
Anssi Hannula says: ==================== net: macb: DMA race condition fixes Here are a couple of race condition fixes for the macb driver. The first two are for issues observed at runtime on real HW. v2: - added received Tested-bys and Acked-bys to the first two patches - in patch 3/3, moved the timestamp protection barrier closer to the timestamp reads - in patch 3/3, removed unnecessary move of the addr assignment in gem_rx() to keep the patch minimal for maximum clarity - in patch 3/3, clarified commit message and comments The 3/3 is the same one I improperly sent last week as a standalone patch. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2018-12-18net: macb: add missing barriers when reading descriptorsAnssi Hannula
When reading buffer descriptors on RX or on TX completion, an RX_USED/TX_USED bit is checked first to ensure that the descriptors have been populated, i.e. the ownership has been transferred. However, there are no memory barriers to ensure that the data protected by the RX_USED/TX_USED bit is up-to-date with respect to that bit. Specifically: - TX timestamp descriptors may be loaded before ctrl is loaded for the TX_USED check, which is racy as the descriptors may be updated between the loads, causing old timestamp descriptor data to be used. - RX ctrl may be loaded before addr is loaded for the RX_USED check, which is racy as a new frame may be written between the loads, causing old ctrl descriptor data to be used. This issue exists for both macb_rx() and gem_rx() variants. Fix the races by adding DMA read memory barriers on those paths and reordering the reads in macb_rx(). I have not observed any actual problems in practice caused by these being missing, though. Tested on a ZynqMP based system. Fixes: 89e5785fc8a6 ("[PATCH] Atmel MACB ethernet driver") Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-12-18net: macb: fix dropped RX frames due to a raceAnssi Hannula
Bit RX_USED set to 0 in the address field allows the controller to write data to the receive buffer descriptor. The driver does not ensure the ctrl field is ready (cleared) when the controller sees the RX_USED=0 written by the driver. The ctrl field might only be cleared after the controller has already updated it according to a newly received frame, causing the frame to be discarded in gem_rx() due to unexpected ctrl field contents. A message is logged when the above scenario occurs: macb ff0b0000.ethernet eth0: not whole frame pointed by descriptor Fix the issue by ensuring that when the controller sees RX_USED=0 the ctrl field is already cleared. This issue was observed on a ZynqMP based system. Fixes: 4df95131ea80 ("net/macb: change RX path for GEM") Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Tested-by: Claudiu Beznea <claudiu.beznea@microchip.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-12-18net: macb: fix random memory corruption on RX with 64-bit DMAAnssi Hannula
64-bit DMA addresses are split in upper and lower halves that are written in separate fields on GEM. For RX, bit 0 of the address is used as the ownership bit (RX_USED). When the RX_USED bit is unset the controller is allowed to write data to the buffer. The driver does not guarantee that the controller already sees the upper half when the RX_USED bit is cleared, possibly resulting in the controller writing an incoming frame to an address with an incorrect upper half and therefore possibly corrupting unrelated system memory. Fix that by adding the necessary DMA memory barrier between the writes. This corruption was observed on a ZynqMP based system. Fixes: fff8019a08b6 ("net: macb: Add 64 bit addressing support for GEM") Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Acked-by: Harini Katakam <harini.katakam@xilinx.com> Tested-by: Claudiu Beznea <claudiu.beznea@microchip.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Michal Simek <michal.simek@xilinx.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-12-18net: Use __kernel_clockid_t in uapi net_stamp.hDavide Caratti
Herton reports the following error when building a userspace program that includes net_stamp.h: In file included from foo.c:2: /usr/include/linux/net_tstamp.h:158:2: error: unknown type name ‘clockid_t’ clockid_t clockid; /* reference clockid */ ^~~~~~~~~ Fix it by using __kernel_clockid_t in place of clockid_t. Fixes: 80b14dee2bea ("net: Add a new socket option for a future transmit time.") Cc: Timothy Redaelli <tredaelli@redhat.com> Reported-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Davide Caratti <dcaratti@redhat.com> Tested-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-12-18net: macb: restart tx after tx used bit readClaudiu Beznea
On some platforms (currently detected only on SAMA5D4) TX might stuck even the pachets are still present in DMA memories and TX start was issued for them. This happens due to race condition between MACB driver updating next TX buffer descriptor to be used and IP reading the same descriptor. In such a case, the "TX USED BIT READ" interrupt is asserted. GEM/MACB user guide specifies that if a "TX USED BIT READ" interrupt is asserted TX must be restarted. Restart TX if used bit is read and packets are present in software TX queue. Packets are removed from software TX queue if TX was successful for them (see macb_tx_interrupt()). Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-12-18net: bridge: remove unneeded variable 'err'YueHaibing
function br_multicast_toggle now always return 0, so the variable 'err' is unneeded. Also cleanup dead branch in br_changelink. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-12-18qlcnic: remove set but not used variables 'op, cmd_op'YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:1070:5: warning: variable 'op' set but not used [-Wunused-but-set-variable] drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:1342:5: warning: variable 'cmd_op' set but not used [-Wunused-but-set-variable] 'op' never used since introduction in commit 7cb03b2347d5 ("qlcnic: Support VF-PF communication channel commands.") 'cmd_op' not used since commit 6226204bcf20 ("qlcnic: Fix operation type and command type.") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-12-19Bluetooth: hci_h5: Turn off RTL8723BS on suspend, reprobe on resumeHans de Goede
On many devices the RTL8723BS device gets reset during suspend/resume, causing it to lose its firmware and all state. Testing has shown it drops back to communicating at 115200 bps and sends sync-request packages, indicating it has been fully reset. This commit fixes this by queueing a reprobe on resume. This mirrors how USB RTL BT devices, which have the same problem, are handled in the btusb driver, there we set the USB_QUIRK_RESET_RESUME for all RTL devices, which also causes a reprobe on resume. The only difference is that here we need to do the reprobe ourselves. Since we are doing a full reprobe on resume now, we can also turn off the device on suspend to save power while suspended. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19Bluetooth: hci_h5: Add suspend / resume opsHans de Goede
Add support for vendor specific suspend / resume callbacks. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19bpf: log struct/union attribute for forward typeYonghong Song
Current btf internal verbose logger logs fwd type as [2] FWD A type_id=0 where A is the type name. Commit 9d5f9f701b18 ("bpf: btf: fix struct/union/fwd types with kind_flag") introduced kind_flag which can be used to distinguish whether a forward type is a struct or union. Also, "type_id=0" does not carry any meaningful information for fwd type as btf_type.type = 0 is simply enforced during btf verification and is not used anywhere else. This commit changed the log to [2] FWD A struct if kind_flag = 0, or [2] FWD A union if kind_flag = 1. Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-12-18Merge tag 'for-linus-20181218' of git://git.kernel.dk/linux-blockLinus Torvalds
Pull block fix from Jens Axboe: "Correct an ioctl direction for the zoned ioctls" * tag 'for-linus-20181218' of git://git.kernel.dk/linux-block: uapi: linux/blkzoned.h: fix BLKGETZONESZ and BLKGETNRZONES definitions
2018-12-19Bluetooth: hci_intel: clean an indentation issue, remove extraneous spacesColin Ian King
Trivial fix to clean up an indentation issue, remove spaces Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-18Merge tag 'pci-v4.20-fixes-4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci Pull PCI fix from Bjorn Helgaas: "Fix the ACPI APEI error path, which previously queued several uninitialized events (Yanjiang Jin)" * tag 'pci-v4.20-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: PCI/AER: Queue one GHES event, not several uninitialized ones
2018-12-18net: stmmac: Fix an error code in probe()Dan Carpenter
The function should return an error if create_singlethread_workqueue() fails. Fixes: 34877a15f787 ("net: stmmac: Rework and fix TX Timeout code") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-12-18tipc: check group dests after tipc_wait_for_cond()Cong Wang
Similar to commit 143ece654f9f ("tipc: check tsk->group in tipc_wait_for_cond()") we have to reload grp->dests too after we re-take the sock lock. This means we need to move the dsts check after tipc_wait_for_cond() too. Fixes: 75da2163dbb6 ("tipc: introduce communication groups") Reported-and-tested-by: syzbot+99f20222fc5018d2b97a@syzkaller.appspotmail.com Cc: Ying Xue <ying.xue@windriver.com> Cc: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Acked-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-12-19Bluetooth: clean an indentation issue, remove extraneous spaceColin Ian King
Trivial fix to clean up an indentation issue Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-18qed: Fix an error code qed_ll2_start_xmit()Dan Carpenter
We accidentally deleted the code to set "rc = -ENOMEM;" and this patch adds it back. Fixes: d2201a21598a ("qed: No need for LL2 frags indication") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-12-19Bluetooth: hci_serdev: Remove setting of HCI_QUIRK_RESET_ON_CLOSE.Balakrishna Godavarthi
HCI_QUIRK_RESET_ON_CLOSE quirk is required for BT v1.0 based devices, to send a reset command to the chip during hci device close. Serdev architecture is used for the latest BT chips, which doesn't require to send the reset command during close. If still chips required reset command during close, it would be better enabling it in the vendor probes or in proto setup. Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19Bluetooth: Remove unnecessary smp_mb__after_atomic() barriersAndrea Parri
The barriers are redundant because atomic_test_and_clear_bit() already provides the required full ordering for the cases in question (that is, when the bit is cleared). Signed-off-by: Andrea Parri <andrea.parri@amarulasolutions.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19Merge branch 'bpf-sk-msg-size-member'Daniel Borkmann
John Fastabend says: ==================== This adds a size field to the sk_msg_md data structure used by SK_MSG programs. Without this in the zerocopy case and in the copy case where multiple iovs are in use its difficult to know how much data can be pulled in. The normal method of reading data and data_end only give the current contiguous buffer. BPF programs can attempt to pull in extra data but have to guess if it exists. This can result in multiple "guesses" its much better if we know upfront the size of the sk_msg. ==================== Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-12-19Bluetooth: btbcm: Add default address for BCM43430A0Chen-Yu Tsai
The BCM43430A0 has the default MAC address 43:43:A0:12:1F:AC if none is given. This address was found when enabling Bluetooth on a bunch of boards with the AMPAK AP6210 module, all sharing the same address. It also contains the sequence 4343A0, which is suspicious as that is also the name the chip identifies itself as. Add this to the list of default MAC addresses and leave it to the user to configure a valid one. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19Bluetooth: hci_bcm: Add compatible string for BCM4330Chen-Yu Tsai
The BCM4330 chip is a 802.11 a/b/g/n + Bluetooth 4.0 + HS controller. This patch adds a compatible string match to the serdev driver for the Bluetooth part of the chip. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19Bluetooth: hci_bcm: Add BCM20702A1 variantMaxime Ripard
The BCM20702A1 chip is a single-chip Bluetooth 4.0 controller and transceiver. It is found in the AMPAK AP6210 WiFi+BT package. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Tested-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19Bluetooth: hci_bcm: Wait for device to come out of reset after power onChen-Yu Tsai
The datasheets for BCM20702 and BCM43438 both have power up time sequence graphs, however they are slightly different. Both chips also have an internal power-on-reset, which holds the chip in reset for a short time after the regulators are enabled. For the BCM20702, the time period from when the regulators are enabled, until the chip settles and comes out of sleep state, is 6564 ~ 8171 us. For the BCM43438, the graph only shows the time period from when the regulators are enabled until the chip responds by driving the host's CTS line low, assuming the host has already driven its RTS line low. This is shown to be 6.5 sleep cycles, with the sleep clock at 32.768 kHz. This is around 2 ms. Wait a full 10 ms after the regulators are enabled to account for signal rising times. Tested-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19Bluetooth: hci_bcm: Add support for regulator suppliesChen-Yu Tsai
The Broadcom Bluetooth chips have two power inputs, VBAT and VDDIO. The former provides overall power for the chip, while the latter powers the I/O pins and buffers. Model these two as regulator supplies, and let the driver manage them in the same way as it does the clock supply. Tested-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19Bluetooth: hci_bcm: Add support for LPO clockChen-Yu Tsai
The Broadcom Bluetooth controllers support a secondary LPO clock at 32.768 kHz. This external clock provides low power timing, and also a way to detect the frequency of the main reference clock. On many designs without NVRAM and a non-default reference clock, this must be used or the controller will not function correctly. Tested-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19Bluetooth: hci_bcm: Use "txco" and "extclk" to get clock referenceChen-Yu Tsai
Originally the device tree binding only specified one clock reference, with the name "extclk". The driver simply retrieves the clock without bothering to specify a name. Since we added a second clock to the binding, we need to fetch the clocks by name now. First we try the new name "txco", then fall back to the old name "extclk", and finally try retrieving a clock without using any name, to cover any instances where a bad device tree or firmware worked by accident. In the last case, we should take care that we don't get the same clock twice when we add support for the "lpo" clock. Tested-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19Bluetooth: hci_bcm: Simplify clk_get error handlingChen-Yu Tsai
The driver currently checks the clk pointer for an error condition, as returned by clk_get, before every invocation of the clk consumer API. This is redundant if the goal is simply to ignore the errors, thereby making the clk optional. The clk consumer API already checks if the pointer is NULL or not. Simplify the code a bit by assigning NULL to the clk pointer if the error condition is one we want to ignore, which is every error except deferred probing. Tested-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19Bluetooth: hci_bcm: Handle deferred probing for the clock supplyChen-Yu Tsai
On some systems that actually have the bluetooth controller wired up with an extra clock signal, it's possible the bluetooth controller probes before the clock provider. clk_get would return a defer probe error, which was not handled by this driver. Handle this properly, so that these systems can work reliably. Tested-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19dt-bindings: net: broadcom-bluetooth: Add BCM4330 compatible stringChen-Yu Tsai
The BCM4330 is a 802.11 a/b/g/n WiFi + Bluetooth 4.0 chip from Broadcom. It is found in the Ampak AP6330 WiFi+BT module. The partiular one I have identifies as BCM4330B1 for Bluetooth and BCM4330/4 for WiFi. It is unclear if the AP6330 module uses this revision of the BCM4330, or if there are multiple revisions. The module does not have revision markings. This patch elects to use just BCM4330 for the compatible string. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19dt-bindings: net: broadcom-bluetooth: Add BCM20702A1 compatible stringChen-Yu Tsai
The BCM20702A1 is a Bluetooth 4.0 chip from Broadcom. It is found in the Ampak AP6210 WiFi+BT module, identified from the read verbose config info command response. However the Bluetooth firmware provided by vendors uses the name BCM20710. This patch elects to use the chip ID returned by the chip for the compatible string. Reviewed-by: Rob Herring <robh@kernel.org> Tested-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19dt-bindings: net: broadcom-bluetooth: Add VBAT and VDDIO suppliesChen-Yu Tsai
The Broadcom Bluetooth chips have two power inputs, VBAT and VDDIO. The former provides overall power for the chip, while the latter powers the I/O pins and buffers. This patch adds properties for the two so we can describe the power supply relationships. Reviewed-by: Rob Herring <robh@kernel.org> Tested-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19dt-bindings: net: broadcom-bluetooth: Fix external clock namesChen-Yu Tsai
The Broadcom Bluetooth controllers can take up to two external clocks: an external frequency reference, substituting the main crystal, and a LPO clock at 32.768 kHz substituting the internal LPO clock. In particular, the external LPO clock must be used when the controller does not have NVRAM connected, and the main reference frequency is not the default 20 MHz. This is described in detail in the datasheet. The original "extclk" clock name is ambiguous as to which of these it refers to, and some designs might even require both. This patch deprecates the existing name, and adds "txco" and "lpo". Tested-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19Bluetooth: Change to use DEFINE_SHOW_ATTRIBUTE macroYangtao Li
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-196lowpan: convert to DEFINE_SHOW_ATTRIBUTEYangtao Li
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19bpf: sk_msg, add tests for size fieldJohn Fastabend
This adds tests to read the size field to test_verifier. Signed-off-by: John Fastabend <john.fastabend@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-12-19bpf: add tools lib/include support sk_msg_md size fieldJohn Fastabend
Add the size field to sk_msg_md for tools. Signed-off-by: John Fastabend <john.fastabend@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-12-19bpf: sockmap, metadata support for reporting size of msgJohn Fastabend
This adds metadata to sk_msg_md for BPF programs to read the sk_msg size. When the SK_MSG program is running under an application that is using sendfile the data is not copied into sk_msg buffers by default. Rather the BPF program uses sk_msg_pull_data to read the bytes in. This avoids doing the costly memcopy instructions when they are not in fact needed. However, if we don't know the size of the sk_msg we have to guess if needed bytes are available by doing a pull request which may fail. By including the size of the sk_msg BPF programs can check the size before issuing sk_msg_pull_data requests. Additionally, the same applies for sendmsg calls when the application provides multiple iovs. Here the BPF program needs to pull in data to update data pointers but its not clear where the data ends without a size parameter. In many cases "guessing" is not easy to do and results in multiple calls to pull and without bounded loops everything gets fairly tricky. Clean this up by including a u32 size field. Note, all writes into sk_msg_md are rejected already from sk_msg_is_valid_access so nothing additional is needed there. Signed-off-by: John Fastabend <john.fastabend@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-12-18drm/amd/display: Optimize passive update planes.Yongqiang Sun
[Why] passive update planes still spends a litte more time on some cases. [How] Remove unnecessary trace which involving in some register read. Disable debug output for release build. Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-12-18drm/amd/display: verify lane status before exiting verify link capWenjing Liu
[why] DP LL CTS1.4 4.3.2.1 test failure. [how] The failure is caused by not handling DP link loss hpd short pusle during set mode. The change is to read link status before set mode link training. If link is lost, re-verify link caps. Signed-off-by: Wenjing Liu <Wenjing.Liu@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>