summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2018-03-20net: dsa: mv88e6xxx: Fix interrupt name for g2 irqUwe Kleine-König
This changes the respective line in /proc/interrupts from 49: x x mv88e6xxx-g1 7 Edge mv88e6xxx-g1 to 49: x x mv88e6xxx-g1 7 Edge mv88e6xxx-g2 which makes more sense. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-20net: dsa: mv88e6xxx: Fix typo in a commentUwe Kleine-König
Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-20net: dsa: mv88e6xxx: Fix name of switch 88E6141Uwe Kleine-König
The switch name is emitted in the kernel log, so having the right name there is nice. Fixes: 1558727a1c1b ("net: dsa: mv88e6xxx: Add support for ethernet switch 88E6141") Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-20clk: scmi: use devm_of_clk_add_hw_provider() API and drop scmi_clocks_removeSudeep Holla
Commit aa795c41d9cd ("clk: Add devm_of_clk_add_hw_provider()/del_provider() APIs") adds devm_of_clk_add_hw_provider which takes care of deleting the clock provider when the clock providers device is removed. This patch makes use of devm_of_clk_add_hw_provider() instead of of_clk_add_hw_provider() so that we can eliminate the need of explicit scmi_clocks_remove for just doing of_clk_del_provider() Acked-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-03-20drm/meson: Fix potential NULL dereference in meson_drv_bind_master()Wei Yongjun
platform_get_resource_byname() may fail and return NULL, so we should better check it's return value to avoid a NULL pointer dereference a bit later in the code. This is detected by Coccinelle semantic patch. @@ expression pdev, res, n, t, e, e1, e2; @@ res = platform_get_resource_byname(pdev, t, n); + if (!res) + return -EINVAL; ... when != res == NULL e = devm_ioremap(e1, res->start, e2); Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/1521555630-29284-1-git-send-email-weiyongjun1@huawei.com
2018-03-20mlxsw: spectrum_acl: Do not invalidate already invalid ACL groupsIdo Schimmel
When a new ACL group is created its region (ACL) list is initially empty. Thus, the call to mlxsw_sp_acl_tcam_group_update() would basically invalidate an already invalid (non-existent) group. Remove the unnecessary call and make the function symmetric to its del() counterpart. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-20mlxsw: spectrum_acl: Adapt ACL configuration to new firmware versionsIdo Schimmel
The driver currently creates empty ACL groups, binds them to the requested port and then fills them with actual ACLs that point to TCAM regions. However, empty ACL groups are considered invalid and upcoming firmware versions are going to forbid their binding. Work around this limitation by only performing the binding after the first ACL was added to the group. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-20mlxsw: spectrum: Reserved field in mbox profile shouldn't be setTal Bar
There is no need to set some of the fields within 'mbox_config_profile', since they are reserved and capability mask should be set to zero. Signed-off-by: Tal Bar <talb@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>
2018-03-20mlxsw: pci: Set mbox dma addresses to zero when not usedShalom Toledo
Some of the opcodes don't use in, out or both mboxes. In such cases, the mbox address is a reserved field and FW expects it to be zero. Signed-off-by: Shalom Toledo <shalomt@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-20net: gemini: fix memory leakIgor Pylypiv
cppcheck report: [drivers/net/ethernet/cortina/gemini.c:543]: (error) Memory leak: skb_tab Signed-off-by: Igor Pylypiv <igor.pylypiv@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-20net: ethernet: arc: Fix a potential memory leak if an optional regulator is ↵Christophe JAILLET
deferred If the optional regulator is deferred, we must release some resources. They will be re-allocated when the probe function will be called again. Fixes: 6eacf31139bf ("ethernet: arc: Add support for Rockchip SoC layer device tree bindings") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-20vmxnet3: remove unused flag "rxcsum" from struct vmxnet3_adapterIgor Pylypiv
Signed-off-by: Igor Pylypiv <ipylypiv@silver-peak.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-20mlx5: Remove call to ida_pre_getMatthew Wilcox
The mlx5 driver calls ida_pre_get() in a loop for no readily apparent reason. The driver uses ida_simple_get() which will call ida_pre_get() by itself and there's no need to use ida_pre_get() unless using ida_get_new(). Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-20Merge branch 'for-upstream' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Johan Hedberg says: ==================== Here are a few more important Bluetooth driver fixes for the 4.16 kernel. Please let me know if there are any issues pulling. Thanks. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-20firmware: arm_scmi: prevent accessing rate_discrete uninitializedAnders Roxell
gcc-5.3 and earlier warns that rate_discrete maybe-uninitialized ../drivers/firmware/arm_scmi/clock.c:185:5: warning: 'rate_discrete' may be used uninitialized in this function [-Wmaybe-uninitialized] if (rate_discrete) ^ ../drivers/firmware/arm_scmi/clock.c:128:7: note: 'rate_discrete' was declared here bool rate_discrete; ^ This patch fixing the warning by initialising rate_discrete and also using goto label for the error path. Fixes: 5f6c6430e904 ("firmware: arm_scmi: add initial support for clock protocol") Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Anders Roxell <anders.roxell@linaro.org> [sudeep.holla: added one line description to the commit message] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-03-20hwmon: (scmi) return -EINVAL when sensor information is unavailableSudeep Holla
Passing NULL pointer to PTR_ERR will result in return value of 0 indicating success which is clearly not what it is intended here. This patch returns -EINVAL instead when the sensor information is not available. Fixes: b23688aefb8b ("hwmon: add support for sensors exported via ARM SCMI") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Guenter Roeck <linux@roeck-us.net> Cc: linux-hwmon@vger.kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-03-20USB: misc: uss720: more vendor/product ID'sDaniel Gimpelevich
Reporting two more VID/PID pairs that work with this driver, having used an informational webpage <http://reboots.g-cipher.net/lcd/> as a buying guide now. The page listed additional working VID/PID pairs but did not include these two. None were upstreamed. Also taking this opportunity to sort the pairs numerically. Of the two such cables now in my possession, one is white, bearing the In-System Design ISD-103 label on one side, sold as an Epson CAEUL0002 "USB to Parallel Smart Cable For Apple Macintosh Computers" (04b8:0002), and the other is black, bearing the In-System Design ISD-101 label on one side, sold as an early Belkin F5U002 (05ab:0002). Signed-off-by: Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-03-20cpufreq: tegra186: Don't validate the frequency table twiceViresh Kumar
The cpufreq core is already validating the CPU frequency table after calling the ->init() callback of the cpufreq drivers and the drivers don't need to do the same anymore. Though they need to set the policy->freq_table field directly from the ->init() callback now. Stop validating the frequency table from tegra186 driver. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20cpufreq: speedstep: Don't validate the frequency table twiceViresh Kumar
The cpufreq core is already validating the CPU frequency table after calling the ->init() callback of the cpufreq drivers and the drivers don't need to do the same anymore. Though they need to set the policy->freq_table field directly from the ->init() callback now. Stop validating the frequency table from speedstep driver. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20cpufreq: sparc: Don't validate the frequency table twiceViresh Kumar
The cpufreq core is already validating the CPU frequency table after calling the ->init() callback of the cpufreq drivers and the drivers don't need to do the same anymore. Though they need to set the policy->freq_table field directly from the ->init() callback now. Stop validating the frequency table from sparc driver. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20cpufreq: sh: Don't validate the frequency table twiceViresh Kumar
The cpufreq core is already validating the CPU frequency table after calling the ->init() callback of the cpufreq drivers and the drivers don't need to do the same anymore. Though they need to set the policy->freq_table field directly from the ->init() callback now. Stop validating the frequency table from sh-cpufreq driver. The driver though prints the min/max frequency values and the same is done from the ->ready() callback now to keep the behavior unchanged. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20cpufreq: sfi: Don't validate the frequency table twiceViresh Kumar
The cpufreq core is already validating the CPU frequency table after calling the ->init() callback of the cpufreq drivers and the drivers don't need to do the same anymore. Though they need to set the policy->freq_table field directly from the ->init() callback now. Stop validating the frequency table from sfi driver. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20cpufreq: scpi: Don't validate the frequency table twiceViresh Kumar
The cpufreq core is already validating the CPU frequency table after calling the ->init() callback of the cpufreq drivers and the drivers don't need to do the same anymore. Though they need to set the policy->freq_table field directly from the ->init() callback now. Stop validating the frequency table from scpi driver. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20cpufreq: sc520: Don't validate the frequency table twiceViresh Kumar
The cpufreq core is already validating the CPU frequency table after calling the ->init() callback of the cpufreq drivers and the drivers don't need to do the same anymore. Though they need to set the policy->freq_table field directly from the ->init() callback now. Stop validating the frequency table from sc520 driver. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20cpufreq: s3c24xx: Don't validate the frequency table twiceViresh Kumar
The cpufreq core is already validating the CPU frequency table after calling the ->init() callback of the cpufreq drivers and the drivers don't need to do the same anymore. Though they need to set the policy->freq_table field directly from the ->init() callback now. Stop validating the frequency table from s3c24xx driver. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20cpufreq: qoirq: Don't validate the frequency table twiceViresh Kumar
The cpufreq core is already validating the CPU frequency table after calling the ->init() callback of the cpufreq drivers and the drivers don't need to do the same anymore. Though they need to set the policy->freq_table field directly from the ->init() callback now. Stop validating the frequency table from qoirq driver. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20cpufreq: pxa: Don't validate the frequency table twiceViresh Kumar
The cpufreq core is already validating the CPU frequency table after calling the ->init() callback of the cpufreq drivers and the drivers don't need to do the same anymore. Though they need to set the policy->freq_table field directly from the ->init() callback now. Stop validating the frequency table from pxa driver. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20cpufreq: ppc_cbe: Don't validate the frequency table twiceViresh Kumar
The cpufreq core is already validating the CPU frequency table after calling the ->init() callback of the cpufreq drivers and the drivers don't need to do the same anymore. Though they need to set the policy->freq_table field directly from the ->init() callback now. Stop validating the frequency table from ppc_cbe driver. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20cpufreq: powernow: Don't validate the frequency table twiceViresh Kumar
The cpufreq core is already validating the CPU frequency table after calling the ->init() callback of the cpufreq drivers and the drivers don't need to do the same anymore. Though they need to set the policy->freq_table field directly from the ->init() callback now. Stop validating the frequency table from powernow driver. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20cpufreq: p4-clockmod: Don't validate the frequency table twiceViresh Kumar
The cpufreq core is already validating the CPU frequency table after calling the ->init() callback of the cpufreq drivers and the drivers don't need to do the same anymore. Though they need to set the policy->freq_table field directly from the ->init() callback now. Stop validating the frequency table from p4-clockmod driver. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20cpufreq: mediatek: Don't validate the frequency table twiceViresh Kumar
The cpufreq core is already validating the CPU frequency table after calling the ->init() callback of the cpufreq drivers and the drivers don't need to do the same anymore. Though they need to set the policy->freq_table field directly from the ->init() callback now. Stop validating the frequency table from mediatek driver. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20cpufreq: longhaul: Don't validate the frequency table twiceViresh Kumar
The cpufreq core is already validating the CPU frequency table after calling the ->init() callback of the cpufreq drivers and the drivers don't need to do the same anymore. Though they need to set the policy->freq_table field directly from the ->init() callback now. Stop validating the frequency table from longhaul driver. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20cpufreq: ia64-acpi: Don't validate the frequency table twiceViresh Kumar
The cpufreq core is already validating the CPU frequency table after calling the ->init() callback of the cpufreq drivers and the drivers don't need to do the same anymore. Though they need to set the policy->freq_table field directly from the ->init() callback now. Stop validating the frequency table from ia64-acpi driver. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20cpufreq: elanfreq: Don't validate the frequency table twiceViresh Kumar
The cpufreq core is already validating the CPU frequency table after calling the ->init() callback of the cpufreq drivers and the drivers don't need to do the same anymore. Though they need to set the policy->freq_table field directly from the ->init() callback now. Stop validating the frequency table from elanfreq driver. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20cpufreq: e_powersaver: Don't validate the frequency table twiceViresh Kumar
The cpufreq core is already validating the CPU frequency table after calling the ->init() callback of the cpufreq drivers and the drivers don't need to do the same anymore. Though they need to set the policy->freq_table field directly from the ->init() callback now. Stop validating the frequency table from e_powersaver driver. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20cpufreq: cpufreq-dt: Don't validate the frequency table twiceViresh Kumar
The cpufreq core is already validating the CPU frequency table after calling the ->init() callback of the cpufreq drivers and the drivers don't need to do the same anymore. Though they need to set the policy->freq_table field directly from the ->init() callback now. Stop validating the frequency table from cpufreq-dt driver. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20cpufreq: brcmstb: Don't validate the frequency table twiceViresh Kumar
The cpufreq core is already validating the CPU frequency table after calling the ->init() callback of the cpufreq drivers and the drivers don't need to do the same anymore. Though they need to set the policy->freq_table field directly from the ->init() callback now. Stop validating the frequency table from brcmstb driver. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20cpufreq: arm_big_little: Don't validate the frequency table twiceViresh Kumar
The cpufreq core is already validating the CPU frequency table after calling the ->init() callback of the cpufreq drivers and the drivers don't need to do the same anymore. Though they need to set the policy->freq_table field directly from the ->init() callback now. Stop validating the frequency table from arm_big_little driver. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20cpufreq: ACPI: Don't validate the frequency table twiceViresh Kumar
The cpufreq core is already validating the CPU frequency table after calling the ->init() callback of the cpufreq drivers and the drivers don't need to do the same anymore. Though they need to set the policy->freq_table field directly from the ->init() callback now. Stop validating the frequency table in the acpi-cpufreq driver. The driver needs to crosscheck if the max frequency corresponds to the P-state 0 or not and the same is done from the ->ready() callback now. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20cpufreq: Don't validate cpufreq table from cpufreq_generic_init()Viresh Kumar
The cpufreq table is already validated by the cpufreq core and none of the users of cpufreq_generic_init() have any dependency on it to validate the table as well. Don't validate the cpufreq table anymore from cpufreq_generic_init(). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20cpufreq: imx6q: Find max freq from frequency table itselfViresh Kumar
This is a preparatory commit to make policy->suspend_freq independent of validation of the cpufreq table, as a later commit would update cpufreq_generic_init() to not validate the cpufreq table any longer. The driver already assumes the order in which the frequency table is sorted and we can get the max frequency easily. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20mtd: rawnand: gpmi: use core timings instead of an empirical derivationMiquel Raynal
GPMI driver timings derivation looks very empirical and does not use the known timings that the core wants to use with the NAND chip, by using local defined constants that have no special meaning from the outside world. Simplify the way all of this is computed and use the NAND core's SDR timings. Integrity of the reads/writes has been checked with nandbiterrs, speed improvements with flash_speed on a Freescale i.MX6 DualLite/Solo SABRE Automotive Board. Measures are below, variations of less than 150kiB/s between tests are common and then not significant. Speeds using mode 5 are the same, while speeds using mode 0 are quite improved (+40/50% from non-optimal computation). Forcing timings mode 0: ======================= Before this patch: ------------------ eraseblock write speed is 2298 KiB/s eraseblock read speed is 3636 KiB/s page write speed is 2136 KiB/s page read speed is 3316 KiB/s 2 page write speed is 2199 KiB/s 2 page read speed is 3468 KiB/s After this patch: ----------------- eraseblock write speed is 3232 KiB/s eraseblock read speed is 5663 KiB/s page write speed is 2915 KiB/s page read speed is 4904 KiB/s 2 page write speed is 3084 KiB/s 2 page read speed is 5267 KiB/s Forcing timings mode 5: ======================= Before this patch: ------------------ eraseblock write speed is 4338 KiB/s eraseblock read speed is 14883 KiB/s page write speed is 3786 KiB/s page read speed is 12800 KiB/s 2 page write speed is 4076 KiB/s 2 page read speed is 14065 KiB/s After this patch: ----------------- eraseblock write speed is 4309 KiB/s eraseblock read speed is 14712 KiB/s page write speed is 3764 KiB/s page read speed is 12673 KiB/s 2 page write speed is 4076 KiB/s 2 page read speed is 14065 KiB/s Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
2018-03-20mtd: rawnand: gpmi: support ->setup_data_interface()Miquel Raynal
Until now the GPMI driver had its own timings logic while the core already handles that and request the NAND controller drivers to support the ->setup_data_interface() hook. Implement that hook by reusing the already existing function. No real glue is necessary between core timing delays and GPMI registers because the driver already translates the ONFI timing modes into register values. Make use of the core's tREA, tRLOH and tRHOH values that allow computing more precise timings for mode [0-3] and get significantly better values (+20% with an i.MX6 Sabre Auto board). Otherwise use the existing logic. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Han Xu <han.xu@nxp.com> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
2018-03-20mtd: rawnand: get rid of the ONFI parameter page in nand_chipMiquel Raynal
The NAND chip parameter page is statically allocated within the nand_chip structure, which reserves a lot of space. Even not ONFI nor JEDEC chips have it embedded. Also, only a few parameters are actually read from the parameter page after the detection. Now that there is a small nand_parameters structure that hold all needed ONFI parameters, remove the ONFI page from the nand_chip structure by just allocating it during the identification phase and removing it right after. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
2018-03-20mtd: rawnand: get rid of the JEDEC parameter page in nand_chipMiquel Raynal
The NAND chip parameter page is statically allocated within the nand_chip structure, which reserves a lot of space. Even not ONFI nor JEDEC chips have it embedded. Also, only a few parameters are actually read from the parameter page after the detection. Now that there is a small nand_parameters structure that can held generic parameters, remove the JEDEC page from the nand_chip structure by just allocating it during the identification phase and removing it right after. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
2018-03-20mtd: rawnand: macronix: nack the support of changing timings for one chipMiquel Raynal
The MX30LF2G18AC chip declares in its parameter page supporting SET/GET_FEATURES but when it comes to timings, experience shows that it is not the case. Unflag this feature for this particular chip in the nand_parameters structure to avoid unnecessary errors and downturns. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
2018-03-20mtd: rawnand: allow vendors to declare (un)supported featuresMiquel Raynal
If SET/GET_FEATURES is available (from the parameter page), use a bitmap to declare what feature is actually supported. Initialize the bitmap in the core to support timing changes (only feature used by the core), also add support for Micron specific features used in Micron initialization code (in the init routine). Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
2018-03-20mtd: rawnand: prepare the removal of the ONFI parameter pageMiquel Raynal
The NAND chip parameter page is statically allocated within the nand_chip structure, which reserves a lot of space. Even not ONFI nor JEDEC chips have it embedded. Also, only a few parameters are actually read from the parameter page after the detection. ONFI-related parameters that will be used outside from the identification function are stored in a separate onfi_parameters structure embedded in nand_parameters, this small structure that already hold generic parameters. For now, the onfi_parameters structure is allocated statically. However, after some deep rework in the NAND framework, it will be possible to do dynamic allocations from the NAND identification phase, and this strcuture will then be dynamically allocated when needed. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
2018-03-20drm/sun4i: hdmi: Fix another error handling path in 'sun4i_hdmi_bind()'Christophe JAILLET
If we can not get the HDMI DDC clock, we still need to free some resources before returning. Fixes: 939d749ad664 ("drm/sun4i: hdmi: Add support for controller hardware variants") Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/5e0084af4ad57e9eea3bca5bd8e2e95970cd6714.1521413031.git.christophe.jaillet@wanadoo.fr
2018-03-20drm/sun4i: hdmi: Fix an error handling path in 'sun4i_hdmi_bind()'Christophe JAILLET
If we can not allocate the HDMI encoder regmap, we still need to free some resources before returning. Fixes: 4b1c924b1fc1 ("drm/sun4i: hdmi: create a regmap for later use") Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/14c42391e1b562c7495bda6ad6fa1d24ec8dc052.1521413031.git.christophe.jaillet@wanadoo.fr