Update maintainer entry for qla2xxx driver now that email addresses have
been changed to Marvell.
Link: https://lore.kernel.org/r/20191001153338.28765-1-hmadhani@marvell.com
Signed-off-by: Himanshu Madhani <hmadhani@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
On excessive bit errors for the FCP channel ingress fibre path, the channel
notifies us. Previously, we only emitted a kernel message and a trace
record. Since performance can become suboptimal with I/O timeouts due to
bit errors, we now stop using an FCP device by default on channel
notification so multipath on top can timely failover to other paths. A new
module parameter zfcp.ber_stop can be used to get zfcp old behavior.
User explanation of new kernel message:
* Description:
* The FCP channel reported that its bit error threshold has been exceeded.
* These errors might result from a problem with the physical components
* of the local fibre link into the FCP channel.
* The problem might be damage or malfunction of the cable or
* cable connection between the FCP channel and
* the adjacent fabric switch port or the point-to-point peer.
* Find details about the errors in the HBA trace for the FCP device.
* The zfcp device driver closed down the FCP device
* to limit the performance impact from possible I/O command timeouts.
* User action:
* Check for problems on the local fibre link, ensure that fibre optics are
* clean and functional, and all cables are properly plugged.
* After the repair action, you can manually recover the FCP device by
* writing "0" into its "failed" sysfs attribute.
* If recovery through sysfs is not possible, set the CHPID of the device
* offline and back online on the service element.
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Cc: <stable@vger.kernel.org> #2.6.30+
Link: https://lore.kernel.org/r/20191001104949.42810-1-maier@linux.ibm.com
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
When a non-passthrough command is terminated with CHECK CONDITION, request
sense is executed by hijacking the command descriptor. Since
scsi_eh_prep_cmnd() and scsi_eh_restore_cmnd() do not save/restore the
original command resid, the value returned on failure of the original
command is lost and replaced with the value set by the execution of the
request sense command. This value may in many instances be unaligned to the
device sector size, causing sd_done() to print a warning message about the
incorrect unaligned resid before the command is retried.
Fix this problem by saving the original command residual in struct
scsi_eh_save using scsi_eh_prep_cmnd() and restoring it in
scsi_eh_restore_cmnd(). In addition, to make sure that the request sense
command is executed with a correctly initialized command structure, also
reset the residual to 0 in scsi_eh_prep_cmnd() after saving the original
command value in struct scsi_eh_save.
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20191001074839.1994-1-damien.lemoal@wdc.com
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The addr variable in prom_free_prom_memory() has been unused since
commit b3c948e2c0 ("MIPS: msp: Record prom memory"), causing a warning
& build failure due to -Werror. Remove the unused variable.
Signed-off-by: Paul Burton <paul.burton@mips.com>
Fixes: b3c948e2c0 ("MIPS: msp: Record prom memory")
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: linux-mips@vger.kernel.org
Commit b3c948e2c0 ("MIPS: msp: Record prom memory") introduced use of
a MAX_PROM_MEM value but didn't define it. A bounds check in
prom_meminit() suggests its value was supposed to be 5, so define it as
such & adjust the bounds check to use the macro rather than a magic
number.
Signed-off-by: Paul Burton <paul.burton@mips.com>
Fixes: b3c948e2c0 ("MIPS: msp: Record prom memory")
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: linux-mips@vger.kernel.org
The naming convention for the existing Theobroma boards is
soc-q7module-baseboard, so rk3399-puma-haikou and the in-kernel
devicetrees also follow that scheme.
For some reason in the binding a wrong or outdated naming slipped
in which does not match the used devicetrees and makes the dt-schema
complain now.
Fix this by using the names used in the wild by actual boards.
Fixes: a323a513c7 ("dt-bindings: arm: Convert Rockchip board/soc bindings to json-schema")
[although the issue was also present in the old txt file]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20190917083453.25744-1-heiko@sntech.de
Fix the pinctrl and interrupt specifier for RK808 to use GPIO3_B2. On the
Rockpro64 schematic [1] page 16, it shows GPIO3_B2 used for the interrupt
line PMIC_INT_L from the RK808, and there's a note which translates as:
"PMU termination GPIO1_C5 changed to this".
Tested by setting an RTC wakealarm and checking /proc/interrupts counters.
Without this patch, neither the rockchip_gpio_irq counter for the RK808,
nor the RTC alarm counter increment when the alarm time is reached.
With this patch, both interrupt counters increment by 1 as expected.
[1] http://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf
Fixes: e4f3fb4909 ("arm64: dts: rockchip: add initial dts support for Rockpro64")
Signed-off-by: Hugh Cole-Baker <sigmaris@gmail.com>
Link: https://lore.kernel.org/r/20190921131457.36258-1-sigmaris@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Few, know rk808 pmic regulators VCC[1-4], VCC[6-7], VCC[9-11],
VDD_LOG, VDD_GPU, VDD_CPU_B, VCC3V3_SYS are inputting with vcc_sys
which is 5V power rail from dc_12v.
So, replace the vin-supply of above mentioned regulators
with vcc_sys as per the PMIC-RK808-D page of roc-rk3399-pc
schematics.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Link: https://lore.kernel.org/r/20190919052822.10403-7-jagan@amarulasolutions.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
It is always better practice to follow regulator naming conventions
as per the schematics for future references.
This would indeed helpful to review and check the naming convention
directly on schematics, both for the code reviewers and the developers.
So, rename vcc12v_sys into dc_12v as per rk3399 power tree as per
roc-rk3399-pc schematics.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Link: https://lore.kernel.org/r/20190919052822.10403-6-jagan@amarulasolutions.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
One of the separate General Register Files contains the registers for
controlling the usb2phy, so add the necessary binding compatible for it.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20190917082659.25549-11-heiko@sntech.de
The px30 contains 2 separate clock controllers the regular cru creating
most clocks as well as the pmucru managing the GPLL and some other clocks.
The gpll of course also is needed by the cru, so while we normally do rely
on clock names to associate clocks getting probed later on (for example
xin32k coming from an i2c device in most cases) it is safer to declare the
explicit dependency between the two crus. This makes sure that for example
the clock-framework probes them in the correct order from the start.
The assigned-clocks properties were simply working by chance in the past
so split them accordingly to the 2 crus to honor the loading direction.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20190917082659.25549-9-heiko@sntech.de
These are unused gpio-settings for specific function pins, that
are not used by anything and only clutter up the dtsi.
They can be re-added when a relevant user is added.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20190917082659.25549-8-heiko@sntech.de
The px30-evb exposes uart2 through a uart-to-usb converter on the board
but these pins are shared with the sdmmc controller. With both activated
this results in a race condition depending in the probe order.
Whichever of the two probes first will break the other peripheral.
The px30-evb also exposes uart5 through pin its pin headers, so it's way
saner to use these pins for serial output and keep the sdmmc working in
all cases.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20190917082659.25549-7-heiko@sntech.de
Add the board's pmic (rk809) and hook up the real supplies to their
consumers. This is especially important as cpufreq would otherwise hang
the system when scaling the frequency without adjusting the voltage.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20190917082659.25549-5-heiko@sntech.de
emmc chips are normally hooked up in standard ways using the full 8bit
bus connection, so there should be no need for all future boards to define
this on their own. So add default pin setups for 8bit busses and special
boards really only needing 4 or 1 bit connections can override.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20190917082659.25549-4-heiko@sntech.de
Similar to all other Rockchip SoCs the px30 does not have a static
32kHz clock. Instead it again gets supplied from an external component
like the pmic.
So drop the static clock, so that we can hook up the right one.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20190917082659.25549-2-heiko@sntech.de
Today, put_compat_statfs64() disallows nearly any field value over
2^32 if f_bsize is only 32 bits, but that makes no sense.
compat_statfs64 is there for the explicit purpose of providing 64-bit
fields for f_files, f_ffree, etc. And f_bsize is always only 32 bits.
As a result, 32-bit userspace gets -EOVERFLOW for i.e. large file
counts even with -D_FILE_OFFSET_BITS=64 set.
In reality, only f_bsize and f_frsize can legitimately overflow
(fields like f_type and f_namelen should never be large), so test
only those fields.
This bug was discussed at length some time ago, and this is the proposal
Al suggested at https://lkml.org/lkml/2018/8/6/640. It seemed to get
dropped amid the discussion of other related changes, but this
part seems obviously correct on its own, so I've picked it up and
sent it, for expediency.
Fixes: 64d2ab32ef ("vfs: fix put_compat_statfs64() does not handle errors")
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add a reference to the missing PCIe clock managed by this IP. The
clock resides in the south bridge.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lkml.kernel.org/r/20190627125245.26788-5-miquel.raynal@bootlin.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Armada 3700 PCIe IP relies on the PCIe clock managed by this
driver. For reasons related to the PCI core's organization when
suspending/resuming, PCI host controller drivers must reconfigure
their registers at suspend_noirq()/resume_noirq() which happens after
suspend()/suspend_late() and before resume_early()/resume().
Device link support in the clock framework enforce that the clock
driver's resume() callback will be called before the PCIe
driver's. But, any resume_noirq() callback will be called before all
the registered resume() callbacks.
The solution to support PCIe resume operation is to change the
"priority" of this clock driver PM callbacks to "_noirq()".
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lkml.kernel.org/r/20190627125245.26788-3-miquel.raynal@bootlin.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The PCIe clock is a gated clock which has the same source as GbE0
(both IPs share a set of registers). This source clock is called
'gbe_core' in the driver.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lkml.kernel.org/r/20190627125245.26788-2-miquel.raynal@bootlin.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The prescaler mask for sam9x60 must be 0xff (8 bits).
Being set to 0, means that we cannot set any prescaler, thus the
programmable clocks do not work (except the case with prescaler 0)
Set the mask accordingly in layout struct.
Fixes: 01e2113de9 ("clk: at91: add sam9x60 pmc driver")
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Link: https://lkml.kernel.org/r/1569321191-27606-1-git-send-email-eugen.hristev@microchip.com
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Fix sparse warnings of a 0 being used for a pointer by removing it from
the initialiser.
drivers/clk/hisilicon/clk-hi3660.c:336:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:338:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:340:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:342:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:344:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:346:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:348:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:350:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:352:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:354:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:356:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:358:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:360:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:362:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:364:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:366:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:368:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:370:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:372:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:374:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:376:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:378:71: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:423:68: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:425:68: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:427:68: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:429:68: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:449:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:451:71: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:453:71: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3660.c:455:71: warning: Using plain integer as NULL pointer
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Link: https://lkml.kernel.org/r/20190925112347.14141-2-ben.dooks@codethink.co.uk
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Fix the following warnings from sparse by removing the 0 initialiser
that is actually a pointer.
drivers/clk/hisilicon/clk-hi3670.c:298:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:300:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:302:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:304:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:306:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:308:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:310:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:312:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:314:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:316:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:318:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:320:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:322:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:324:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:326:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:328:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:330:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:332:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:334:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:336:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:338:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:340:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:342:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:344:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:346:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:348:65: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:350:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:352:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:488:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:490:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:492:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:494:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:496:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:498:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:500:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:502:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:504:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:506:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:508:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:510:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:512:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:514:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:516:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:518:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:520:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:522:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:524:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:526:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:528:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:530:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:532:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:534:71: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:536:71: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:538:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:611:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:614:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:616:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:653:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:655:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:657:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:659:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:661:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:663:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:665:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:735:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:737:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:739:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:741:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:743:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:745:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:802:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:804:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:806:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:808:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:810:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:812:69: warning: Using plain integer as NULL pointer
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Link: https://lkml.kernel.org/r/20190925112347.14141-1-ben.dooks@codethink.co.uk
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
sparse warns about incorrect type when using __be64 data.
It is not being converted to CPU-endian but it should be.
Fixes these sparse warnings:
../block/sed-opal.c:375:20: warning: incorrect type in assignment (different base types)
../block/sed-opal.c:375:20: expected unsigned long long [usertype] align
../block/sed-opal.c:375:20: got restricted __be64 const [usertype] alignment_granularity
../block/sed-opal.c:376:25: warning: incorrect type in assignment (different base types)
../block/sed-opal.c:376:25: expected unsigned long long [usertype] lowest_lba
../block/sed-opal.c:376:25: got restricted __be64 const [usertype] lowest_aligned_lba
Fixes: 455a7b238c ("block: Add Sed-opal library")
Cc: Scott Bauer <scott.bauer@intel.com>
Cc: Rafael Antognolli <rafael.antognolli@intel.com>
Cc: linux-block@vger.kernel.org
Reviewed-by: Jon Derrick <jonathan.derrick@intel.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
For rtc drivers where rtc->range_max is set U64_MAX, like the PS3 rtc,
rtc_valid_range() always returns -ERANGE. This is because the local
variable range_max has type time64_t, so the test
if (time < range_min || time > range_max)
return -ERANGE;
becomes (time < range_min || time > -1), which always evaluates to true.
timeu64_t should be used, since it's the type of rtc->range_max.
Signed-off-by: Emmanuel Nicolet <emmanuel.nicolet@gmail.com>
Link: https://lore.kernel.org/r/20190927110446.GA6289@gmail.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Use of_device_get_match_data() since all platforms should now use DT
bindings. AVR32 architecture has been removed in
commit 26202873bb ("avr32: remove support for AVR32 architecture").
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/1569500132-21164-1-git-send-email-claudiu.beznea@microchip.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Add mmc capabilities for SDMMC0 for this board.
With this enabled, eMMC connected card is detected as:
mmc0: new DDR MMC card at address 0001
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Link: https://lore.kernel.org/r/1565252928-28994-2-git-send-email-eugen.hristev@microchip.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
The syzbot fuzzer found a slab-out-of-bounds write bug in the hid-gaff
driver. The problem is caused by the driver's assumption that the
device must have an input report. While this will be true for all
normal HID input devices, a suitably malicious device can violate the
assumption.
The same assumption is present in over a dozen other HID drivers.
This patch fixes them by checking that the list of hid_inputs for the
hid_device is nonempty before allowing it to be used.
Reported-and-tested-by: syzbot+403741a091bf41d4ae79@syzkaller.appspotmail.com
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@vger.kernel.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Oleksij Rempel says:
====================
phy: at803x: add ar9331 support
changes v3:
- use PHY_ID_MATCH_EXACT only for ATH9331 PHY
changes v2:
- use PHY_ID_MATCH_EXACT instead of leaky masking
- remove probe and struct at803x_priv
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
struct at803x_priv is never used in this driver. So remove it
and the probe function allocating it.
Suggested-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Mostly this hardware can work with generic PHY driver, but this change
is needed to provided interrupt handling support.
Tested with dsa ar9331-switch driver.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This reverts commit 4eaceea3a0.
Several userspace clients (modesetting ddx and mutter+wayland at least)
handle encoder.possible_crtcs incorrectly. What they essentially do is
the following:
possible_crtcs = ~0;
for_each_possible_encoder(connector)
possible_crtcs &= encoder->possible_crtcs;
Ie. they calculate the intersection of the possible_crtcs
for the connector when they really should be calculating the
union instead.
In our case each MST encoder now has just one unique bit set,
and so the intersection is always zero. The end result is that
MST connectors can't be lit up because no crtc can be found to
drive them.
I've submitted a fix for the modesetting ddx [1], and complained
on #wayland about mutter, so hopefully the situation will improve
in the future. In the meantime we have regression, and so must go
back to the old way of misconfiguring possible_crtcs in the kernel.
[1] https://gitlab.freedesktop.org/xorg/xserver/merge_requests/277
Cc: Jonas Ådahl <jadahl@gmail.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111507
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190903154018.26357-1-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
(cherry picked from commit e838bfa8e1)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Currently mlxsw distributes sent traffic among all the available send
queues. That includes control traffic as well as EMADs, which are used for
configuration of the device.
However because all the queues have the same traffic class of 3, they all
end up being directed to the same traffic class buffer. If the control
traffic in the buffer cannot be serviced quickly enough, the EMAD traffic
might be shut out, which causes transient failures, typically in FDB
maintenance, counter upkeep and other periodic work.
To address this issue, dedicate SDQ 0 to EMAD traffic, with TC 0.
Distribute the control traffic among the remaining queues, which are left
with their current TC 3.
Suggested-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Petr Machata <petrm@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Clang warns:
lib/test_user_copy.c:96:10: warning: using the result of an assignment
as a condition without parentheses [-Wparentheses]
if (ret |= test(umem_src == NULL, "kmalloc failed"))
~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
lib/test_user_copy.c:96:10: note: place parentheses around the
assignment to silence this warning
if (ret |= test(umem_src == NULL, "kmalloc failed"))
^
( )
lib/test_user_copy.c:96:10: note: use '!=' to turn this compound
assignment into an inequality comparison
if (ret |= test(umem_src == NULL, "kmalloc failed"))
^~
!=
Add the parentheses as it suggests because this is intentional.
Fixes: f5a1a536fa ("lib: introduce copy_struct_from_user() helper")
Link: https://github.com/ClangBuiltLinux/linux/issues/731
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Aleksa Sarai <cyphar@cyphar.com>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Link: https://lore.kernel.org/r/20191003171121.2723619-1-natechancellor@gmail.com
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Currently, RDS calls ib_dma_alloc_coherent() to allocate a large piece
of contiguous DMA coherent memory to store struct rds_header for
sending/receiving packets. The memory allocated is then partitioned
into struct rds_header. This is not necessary and can be costly at
times when memory is fragmented. Instead, RDS should use the DMA
memory pool interface to handle this. The DMA addresses of the pre-
allocated headers are stored in an array. At send/receive ring
initialization and refill time, this arrary is de-referenced to get
the DMA addresses. This array is not accessed at send/receive packet
processing.
Suggested-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Apparently a refactoring patch brought a bug, that was caught
by syzbot [1]
Original code was correct, do not try to be smarter than the
compiler :/
[1]
BUG: KASAN: slab-out-of-bounds in tcp_zerocopy_receive net/ipv4/tcp.c:1807 [inline]
BUG: KASAN: slab-out-of-bounds in do_tcp_getsockopt.isra.0+0x2c6c/0x3120 net/ipv4/tcp.c:3654
Read of size 4 at addr ffff8880943cf188 by task syz-executor.2/17508
CPU: 0 PID: 17508 Comm: syz-executor.2 Not tainted 5.3.0-rc7+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.cold+0xd4/0x306 mm/kasan/report.c:351
__kasan_report.cold+0x1b/0x36 mm/kasan/report.c:482
kasan_report+0x12/0x17 mm/kasan/common.c:618
__asan_report_load4_noabort+0x14/0x20 mm/kasan/generic_report.c:131
tcp_zerocopy_receive net/ipv4/tcp.c:1807 [inline]
do_tcp_getsockopt.isra.0+0x2c6c/0x3120 net/ipv4/tcp.c:3654
tcp_getsockopt+0xbf/0xe0 net/ipv4/tcp.c:3680
sock_common_getsockopt+0x94/0xd0 net/core/sock.c:3098
__sys_getsockopt+0x16d/0x310 net/socket.c:2129
__do_sys_getsockopt net/socket.c:2144 [inline]
__se_sys_getsockopt net/socket.c:2141 [inline]
__x64_sys_getsockopt+0xbe/0x150 net/socket.c:2141
do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296
Fixes: d8e18a516f ("net: Use skb accessors in network core")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Thierry Reding says:
====================
net: stmmac: Enhanced addressing mode for DWMAC 4.10
The DWMAC 4.10 supports the same enhanced addressing mode as later
generations. Parse this capability from the hardware feature registers
and set the EAME (Enhanced Addressing Mode Enable) bit when necessary.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The address width of the controller can be read from hardware feature
registers much like on XGMAC. Add support for parsing the ADDR64 field
so that the DMA mask can be set accordingly.
This avoids getting swiotlb involved for DMA on Tegra186 and later.
Also make sure that the upper 32 bits of the DMA address are written to
the DMA descriptors when enhanced addressing mode is used. Similarily,
for each channel, the upper 32 bits of the DMA descriptor ring's base
address also need to be programmed to make sure the correct memory can
be fetched when the DMA descriptor ring is located beyond the 32-bit
boundary.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Enhanced addressing mode is only required when more than 32 bits need to
be addressed. Add a DMA configuration parameter to enable this mode only
when needed.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Check the number of supported vectors and fall back to MSI if
we return or error or 0 MSI-X vectors.
v2: only allocate one vector. We can't currently use more than
one anyway.
v3: install the irq on vector 0.
Tested-by: Tom St Denis <tom.stdenis@amd.com>
Reviewed-by: Shaoyun liu <shaoyun.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
