- 18 May, 2018 1 commit
-
-
Tony Lindgren authored
We should be checking ddata->clocks[i] instead of clock_names[i] for the optional clocks. Currently this just happens to work for the typical case of one fck and one optional clock. Fixes: 09dfe581 ("bus: ti-sysc: Add handling for clkctrl opt clocks") Cc: Dan Carpenter <dan.carpenter@oracle.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
- 01 May, 2018 7 commits
-
-
Tony Lindgren authored
Let's show module info if DEBUG is enabled to make it easier to follow what happens on the suspend and resume path. Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
Looks like these two device drivers don't yet behave properly for suspend unless configured with the legacy option. Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
Starting with omap4, UARTs have different revision register that we need to detect to enable SYSC_QUIRK_LEGACY_IDLE. Otherwise UARTs won't idle properly. Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
Starting with omap4 some timers have different sysc registers (type2) compared to the omap2 timers (type1). We need to detect these to enable the quirk for SYSC_QUIRK_LEGACY_IDLE, otherwise these won't be idling properly. Siganed-off-by:
Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
Some modules need to use external resets in the rstctrl bits. Typically only one of the rstctrl bits is for the interconnect target module while the others are for various child devices. For ti-sysc driver, we just need the module rstctrl bit mapped. The rest of the rstctrl bits can be directly mapped to the child devices. Cc: Suman Anna <s-anna@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
Based on testing with more devices I noticed that some devices don't suspend or resume properly. We need to PM runtime suspend and resume devices if we have ddata->needs_resume set. Let's also improve the error handling and add few debug statements to make it easier to notice suspend and resume related issues if DEBUG is set. Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
Modules that provide resources for other modules need to be suspended and resumed in the noirq calls. Tag the resource providing modules. Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
- 30 Apr, 2018 3 commits
-
-
Tony Lindgren authored
There can be up to eight optional device functional gate gate clocks for each clkctrl instance in clkctrl register bits 8 to 15. Some of them are only needed for module level reset while others may always be needed during use. Let's add support for those and update the binding doc accordingly. Note that the optional clkctrl mux and divider clocks starting at bit 20 can be directly mapped to the child devices, and ti-sysc does not need to manage those. And as GPIOs need the optional clocks for reset, we can now add it with SYSC_QUIRK_OPT_CLKS_IN_RESET. Cc: Mark Rutland <mark.rutland@arm.com> Cc: Tero Kristo <t-kristo@ti.com> Cc: devicetree@vger.kernel.org Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
In order to prepare supporting clkctrl optional clocks, we need to make the current child clock handling more generic so we can use the clock role names for the optional clocks in the following patch. Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
Otherwise child devices that some interconnect target module devices have won't probe using simple-bus. Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
- 16 Apr, 2018 1 commit
-
-
Tony Lindgren authored
Looks like these functions don't do anything in the mainline kernel so we can just drop it. Note that we must now also remove ir-rx51 pdata as it relies on the dummy platform data that does not do anything. And ir-rx51 is calling a pdata callback that doesn't do anything without checking if it exists first. For configuring device specific minimal latencies, the interface to use is pm_qos_add_request(). For an example, see what was done in commit 9834ffd1 ("ASoC: omap-mcbsp: Add PM QoS support for McBSP to prevent glitches"). I've added some comments to ir-rx51 so people using it can add pm_qos support and test it. Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> Cc: Kevin Hilman <khilman@kernel.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
- 13 Apr, 2018 3 commits
-
-
Jean Delvare authored
RFC 4122 asks for letters a-f in UUID to be lowercase. Follow this recommendation. Suggested by Paul Dagnelie at: https://savannah.nongnu.org/bugs/index.php?53569 Signed-off-by:
Jean Delvare <jdelvare@suse.de>
-
Alex Hung authored
OEM strings are defined by each OEM and they contain customized and useful OEM information. Supporting it provides more flexible uses of the dmi_matches function. Signed-off-by:
Alex Hung <alex.hung@canonical.com> Signed-off-by:
Jean Delvare <jdelvare@suse.de>
-
Jean Delvare authored
The test which ensures that the DMI type 1 structure is long enough to hold the UUID is off by one. It would fail if the structure is exactly 24 bytes long, while that's sufficient to hold the UUID. I don't expect this bug to cause problem in practice because all implementations I have seen had length 8, 25 or 27 bytes, in line with the SMBIOS specifications. But let's fix it still. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Fixes: a814c359 ("firmware: dmi_scan: Check DMI structure length") Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com>
-
- 12 Apr, 2018 18 commits
-
-
Harry Wentland authored
This seems to cause flickering and lock-ups for a wide range of users. Revert until we've found a proper fix for the flickering and lock-ups. This reverts commit 36cc549d . Cc: Shirish S <shirish.s@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Harry Wentland authored
This reverts commit cd2d6c92 . Cc: Shirish S <shirish.s@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Leo (Sunpeng) Li authored
Hardware understands the regamma LUT as a piecewise linear function, with points spaced exponentially along the range. We previously programmed the LUT for range [2^-10, 2^0). This causes (normalized) color values of 1 (=2^0) to miss the programmed LUT, and fall onto the end region. For DCE, the end region is extrapolated using a single (base, slope) pair, using the max y-value from the last point in the curve as base. This presents a problem, since this value affects all three color channels. Scaling down the intensity of say - the blue regamma curve - will not affect it's end region. This is especially noticiable when using RedShift. It scales down the blue and green channels, but leaves full-intensity colors unshifted. Therefore, extend the range to cover [2^-10, 2^1) by programming another hardware segment, containing only one point. That way, we won't be hitting the end region. Note that things are a bit different for DCN, since the end region can be set per-channel. Signed-off-by:
Leo (Sunpeng) Li <sunpeng.li@amd.com> Reviewed-by:
Krunoslav Kovac <Krunoslav.Kovac@amd.com> Acked-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Roman Li authored
Signed-off-by:
Roman Li <roman.li@amd.com> Reviewed-by:
Charlene Liu <Charlene.Liu@amd.com> Acked-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Harry Wentland authored
Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Reviewed-by:
Tony Cheng <Tony.Cheng@amd.com> Acked-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
James Smart authored
The nvmf_check_if_ready() checks that were added are very simplistic. As such, the routine allows a lot of cases to fail ios during windows of reset or re-connection. In cases where there are not multi-path options present, the error goes back to the callee - the filesystem or application. Not good. The common routine was rewritten and calling syntax slightly expanded so that per-transport is_ready routines don't need to be present. The transports now call the routine directly. The routine is now a fabrics routine rather than an inline function. The routine now looks at controller state to decide the action to take. Some states mandate io failure. Others define the condition where a command can be accepted. When the decision is unclear, a generic queue-or-reject check is made to look for failfast or multipath ios and only fails the io if it is so marked. Otherwise, the io will be queued and wait for the controller state to resolve. Admin commands issued via ioctl share a live admin queue with commands from the transport for controller init. The ioctls could be intermixed with the initialization commands. It's possible for the ioctl cmd to be issued prior to the controller being enabled. To block this, the ioctl admin commands need to be distinguished from admin commands used for controller init. Added a USERCMD nvme_req(req)->rq_flags bit to reflect this division and set it on ioctls requests. As the nvmf_check_if_ready() routine is called prior to nvme_setup_cmd(), ensure that commands allocated by the ioctl path (actually anything in core.c) preps the nvme_req(req) before starting the io. This will preserve the USERCMD flag during execution and/or retry. Signed-off-by:
James Smart <james.smart@broadcom.com> Reviewed-by:
Sagi Grimberg <sagi@grimberg.e> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Keith Busch authored
Signed-off-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Daniel Verkamp authored
Commit 42de82a8 previously attempted to fix this, and it did correctly pad the MN and FR fields with spaces, but the SN field still contains 0 bytes. The current code fills out the first 16 bytes with hex2bin, leaving the last 4 bytes zeroed. Rather than adding a lot of error-prone math to avoid overwriting SN twice, just set the whole thing to spaces up front (it's only 20 bytes). Fixes: 42de82a8 ("nvmet: don't report 0-bytes in serial number") Signed-off-by:
Daniel Verkamp <daniel.verkamp@intel.com> Reviewed-by:
Martin Wilck <mwilck@suse.com> Signed-off-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Max Gurtovoy authored
Also add error flow in case srcu initialization function fails. Signed-off-by:
Max Gurtovoy <maxg@mellanox.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Rodrigo R. Galvao authored
We have to increment the number of logical blocks to a 1's based value in the native format prior to converting to 512b units. Signed-off-by:
Rodrigo R. Galvao <rosattig@linux.vnet.ibm.com> [changelog] Signed-off-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Keith Busch authored
The admin and first IO queues shared the first irq vector, which has an affinity mask including cpu0. If a system allows cpu0 to be offlined, the admin queue may not be usable if no other CPUs in the affinity mask are online. This is a problem since unlike IO queues, there is only one admin queue that always needs to be usable. To fix, this patch allocates one pre_vector for the admin queue that is assigned all CPUs, so will always be accessible. The IO queues are assigned the remaining managed vectors. In case a controller has only one interrupt vector available, the admin and IO queues will share the pre_vector with all CPUs assigned. Cc: Jianchao Wang <jianchao.w.wang@oracle.com> Cc: Ming Lei <ming.lei@redhat.com> Signed-off-by:
Keith Busch <keith.busch@intel.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Ming Lei <ming.lei@redhat.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Keith Busch authored
All the queue memory is allocated up front. We don't take the node into consideration when creating queues anymore, so removing the unused parameter. Signed-off-by:
Keith Busch <keith.busch@intel.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Ming Lei <ming.lei@redhat.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Keith Busch authored
User reported controller always retains CSTS.RDY to 1, which fails controller disabling when resetting the controller. This is also before the admin queue is allocated, and trying to disable an unallocated queue results in a NULL dereference. Reported-by:
Alex Gagniuc <Alex_Gagniuc@Dellteam.com> Signed-off-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Arnd Bergmann authored
nvmet_execute_get_disc_log_page() passes a fixed-length string into nvmet_format_discovery_entry(), which then does a longer memcpy() on it, as pointed out by gcc-8: In function 'nvmet_format_discovery_entry', inlined from 'nvmet_execute_get_disc_log_page' at drivers/nvme/target/discovery.c:126:4: drivers/nvme/target/discovery.c:62:2: error: 'memcpy' forming offset [38, 223] is out of the bounds [0, 37] [-Werror=array-bounds] memcpy(e->subnqn, subsys_nqn, NVMF_NQN_SIZE); Using strncpy() will make this well-defined, filling the rest of the buffer with zeroes, under the assumption that the input is either a NUL-terminated string, or a byte sequence containing no zeroes. If the input is a string that is longer than NVMF_NQN_SIZE, we continue to have no NUL-termination in the output. Fixes: a07b4970 ("nvmet: add a generic NVMe target") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Johannes Thumshirn authored
NVMe over Fabrics 1.0 Section 5.2 "Discovery Controller Properties and Command Support" Figure 31 "Discovery Controller – Admin Commands" explicitly listst all commands but "Get Log Page" and "Identify" as reserved, but NetApp report the Linux host is sending Keep Alive commands to the discovery controller, which is a violation of the Spec. We're already checking for discovery controllers when configuring the keep alive timeout but when creating a discovery controller we're not hard wiring the keep alive timeout to 0 and thus remain on NVME_DEFAULT_KATO for the discovery controller. This can be easily remproduced when issuing a direct connect to the discovery susbsystem using: 'nvme connect [...] --nqn=nqn.2014-08.org.nvmexpress.discovery' Signed-off-by:
Johannes Thumshirn <jthumshirn@suse.de> Fixes: 07bfcd09 ("nvme-fabrics: add a generic NVMe over Fabrics library") Reported-by:
Martin George <marting@netapp.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Johannes Thumshirn authored
nvme_start_keep_alive() isn't used outside core.c so unexport it and make it static. Signed-off-by:
Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Ming Lei authored
When nvmet_req_init() fails, __nvmet_req_complete() is called to handle the target request via .queue_response(), so nvme_loop_queue_response() shouldn't be called again for handling the failure. This patch fixes this case by the following way: - move blk_mq_start_request() before nvmet_req_init(), so nvme_loop_queue_response() may work well to complete this host request - don't call nvme_cleanup_cmd() which is done in nvme_loop_complete_rq() - don't call nvme_loop_queue_response() which is done via .queue_response() Signed-off-by:
Ming Lei <ming.lei@redhat.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> [trimmed changelog] Signed-off-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Matias Bjørling authored
Compiling on 32 bits system produces a warning for the shift width when shifting 32 bit integer with 64bit integer. Make sure that offset always is 64bit, and use macros for retrieving lower and upper bits of the offset. Signed-off-by:
Matias Bjørling <mb@lightnvm.io> Signed-off-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
- 11 Apr, 2018 7 commits
-
-
Ard Biesheuvel authored
The API docs describe i2c_transfer() as taking a pointer to an array of i2c_msg containing at least 1 entry, but leaves it to the individual drivers to sanity check the msgs and num parameters. Let's do this in core code instead. Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> [wsa: changed '<= 0' to '< 1'] Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
Jean Delvare authored
On some systems, the BIOS expects certain SMBus register values to match the hardware defaults. Restore these configuration registers at shutdown time to avoid confusing the BIOS. This avoids hard-locking such systems upon reboot. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Tested-by:
Jason Andryuk <jandryuk@gmail.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Cc: stable@vger.kernel.org
-
Jean Delvare authored
Saving the original value of register SMBSLVCMD in i801_enable_host_notify() doesn't work, because this function is called not only at probe time but also at resume time. Do it in i801_probe() instead, so that the saved value is not overwritten at resume time. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Fixes: 22e94bd6 ("i2c: i801: store and restore the SLVCMD register at load and unload") Reviewed-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by:
Jason Andryuk <jandryuk@gmail.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Cc: stable@vger.kernel.org # v4.10+
-
Sabrina Dubroca authored
I added dumping of link information about tun devices over netlink in commit 1ec010e7 ("tun: export flags, uid, gid, queue information over netlink"), but didn't add the missing netlink notifications when the device's exported properties change. This patch adds notifications when owner/group or flags are modified, when queues are attached/detached, and when a tun fd is closed. Reported-by:
Thomas Haller <thaller@redhat.com> Fixes: 1ec010e7 ("tun: export flags, uid, gid, queue information over netlink") Signed-off-by:
Sabrina Dubroca <sd@queasysnail.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sabrina Dubroca authored
Otherwise, register_netdevice advertises the creation of the device with the default flags, instead of what the user requested. Reported-by:
Thomas Haller <thaller@redhat.com> Fixes: 1ec010e7 ("tun: export flags, uid, gid, queue information over netlink") Signed-off-by:
Sabrina Dubroca <sd@queasysnail.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Phil Elwell authored
Commit 92571a1a ("lan78xx: Connect phy early") moves the PHY initialisation into lan78xx_probe, but lan78xx_open subsequently calls lan78xx_reset. As well as forcing a second round of link negotiation, this reset frequently prevents the phy interrupt from being generated (even though the link is up), rendering the interface unusable. Fix this issue by removing the lan78xx_reset call from lan78xx_open. Fixes: 92571a1a ("lan78xx: Connect phy early") Signed-off-by:
Phil Elwell <phil@raspberrypi.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Michael Chan authored
When open fails during ethtool -L ring change, for example, the driver may crash at bnxt_free_irq() because bp->bnapi is NULL. If we fail to allocate all the new rings, bnxt_open_nic() will free all the memory including bp->bnapi. Subsequent call to bnxt_close_nic() will try to dereference bp->bnapi in bnxt_free_irq(). Fix it by checking for !bp->bnapi in bnxt_free_irq(). Fixes: e5811b8c ("bnxt_en: Add IRQ remapping logic.") Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-