css_idr allocation starts at 1, so index 0 will never point to an
item. css_from_id() currently filters that before asking idr_find(),
but idr_find() would also just return NULL, so this is not needed.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
The valid cgroup hierarchy ID range includes 0, so we can't filter for
positive numbers when freeing it, or it'll leak the first ID. No big
deal, just disruptive when reading the code.
The ID is freed during error handling and when the reference count
hits zero, so the double-free test is not necessary; remove it.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
This patch reworks code for generating sparse keymap and processing WMI
events. It unifies procedure for generating sparse keymap and also unifies
big switch code for processing WMI events of different types. After this
patch dell-wmi driver does not differ between "old" and "new" hotkey type.
It constructs sparse keymap table with all WMI codes. It is because on some
laptops (e.g. Dell Latitude E6440) ACPI/firmware send both event types (old
and new).
Each WMI code in sparse keymap table is prefixed by 16bit event type, so it
does not change functionality on laptops with "old" hotkey support (those
without scancodes in DMI).
This allow us to distinguish between same WMI codes with different types in
sparse keymap. Thanks to this WMI events of type 0x0011 were moved from big
switch into sparse keymap table too.
This patch also fixes possible bug in parsing WMI event buffer introduced
in commit 5ea2559726 ("dell-wmi: Add support for new Dell systems"). That
commit changed buffer type from int* to u16* without fixing code. More at:
http://lkml.iu.edu/hypermail/linux/kernel/1507.0/01950.html
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Michał Kępień <kernel@kempniu.pl>
Reviewed-by: Michał Kępień <kernel@kempniu.pl>
Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
ACPI DSDT tables have defined other WMI codes, but does not contain any
description when those codes are emitted. Some other codes can be found in
logs on internet. In this patch are all which I saw, but lot of them are
not tested properly (e.g. for duplicate events with AT keyboard). Now we
have all WMI event codes at one place and in future after proper testing
those codes can be correctly enabled or disabled...
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Michał Kępień <kernel@kempniu.pl>
Reviewed-by: Michał Kępień <kernel@kempniu.pl>
Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
For better readability of keymap table, sort events by codes and also
update comments for events to be more informative.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Michał Kępień <kernel@kempniu.pl>
Reviewed-by: Michał Kępień <kernel@kempniu.pl>
Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
>From Dell we know that WMI event code 0xe045 is for Num Lock key, but it is
unclear due to message in commit 0b3f6109f0 ("dell-wmi: new driver for
hotkey control").
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Michał Kępień <kernel@kempniu.pl>
Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Reviewed-by: Michał Kępień <kernel@kempniu.pl>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Mario Limonciello <mario_limonciello@dell.com>
Link: https://lkml.org/lkml/2015/7/7/830
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
There is no limit on high "idx" can go. It should be less than
ARRAY_SIZE(data.states) which is 16.
The "data" variable wasn't declared in that scope so I shifted the code
around a bit to make it work. Also I made "idx" unsigned.
Fixes: f3898ea12f ('drm/amd/powerplay: add some sysfs interfaces for powerplay.')
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
When we have an interrupt from the host we have a bit set in event page
indicating there are messages for the particular channel. We need to read
them all as we won't get signaled for what was on the queue before we
cleared the bit in vmbus_on_event(). This applies to all Hyper-V drivers
and the pass-through driver should do the same.
I did not meet any bugs; the issue was found by code inspection. We don't
have many events going through hv_pci_onchannelcallback(), which explains
why nobody reported the issue before.
While on it, fix handling non-zero vmbus_recvpacket_raw() return values by
dropping out. If the return value is not zero, it is wrong to inspect
buffer or bytes_recvd as these may contain invalid data.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jake Oshins <jakeo@microsoft.com>
We don't free buffer on several code paths in hv_pci_onchannelcallback(),
put kfree() to the end of the function to fix the issue. Direct { kfree();
return; } can now be replaced with a simple 'break';
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jake Oshins <jakeo@microsoft.com>
- Plug the ongoing spin_unlock_wait/spin_is_locked mess
- KGDB protocol fix to sync w/ GDB
- Fix MIDR-based PMU probing for old 32-bit SMP systems (OMAP4/Realview)
- Minor tweaks to the fault handling path
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABCgAGBQJXY97DAAoJELescNyEwWM08fYH/3QSj8P11PPIoyu1qEs+9kj1
r7lQGLMZoI/VS7OGPmgwpbQRHk227h0Rz4UnQ4/fTharVs5Pv9iPxnFKjCRCVVGK
VuI815tWC+0mKlJ4ztn8cJk7+GgWiZttAn5qWafuXQUTfqm+ywZOxfiU0+aC9Ytn
k5m3G46cyAvrBcNwLFcrwavzdyVjy/O3nEQVWmzT7uXmPknr52BmWjk3VuCMPdYd
tEjoRK3Nt2xMV3E4A6oIINBz1KmmqGVW3Nzx2prD0d0oGwyT+3FDlHbm+b/fn7aK
ti18FPUDiNSE67enYQ1+3wEyn1Ge/0Z/lLnKJxWXv4+qk3zwsCkp4h/SkOqv3fM=
=0YtF
-----END PGP SIGNATURE-----
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Will Deacon:
"The main things are getting kgdb up and running with upstream GDB
after a protocol change was reverted and fixing our spin_unlock_wait
and spin_is_locked implementations after doing some similar work with
PeterZ on the qspinlock code last week. Whilst we haven't seen any
failures in practice, it's still worth getting this fixed.
Summary:
- Plug the ongoing spin_unlock_wait/spin_is_locked mess
- KGDB protocol fix to sync w/ GDB
- Fix MIDR-based PMU probing for old 32-bit SMP systems
(OMAP4/Realview)
- Minor tweaks to the fault handling path"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: kgdb: Match pstate size with gdbserver protocol
arm64: spinlock: Ensure forward-progress in spin_unlock_wait
arm64: spinlock: fix spin_unlock_wait for LSE atomics
arm64: spinlock: order spin_{is_locked,unlock_wait} against local locks
arm: pmu: Fix non-devicetree probing
arm64: mm: mark fault_info table const
arm64: fix dump_instr when PAN and UAO are in use
Three patches queued up:
* Fix for ARM-SMMU to add a missing iommu-ops callback which is
required by common iommu code
* Fix for the rockchip iommu where the wrong MMUs got the
commands
* A regression fix for the Intel VT-d driver. The regression
only showed up on X58 chipsets with more than one iommu. These
chipsets seem to require that QI is enabled on all IOMMUs
before it can be used.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJXZArGAAoJECvwRC2XARrj1zwP+wTP9+bvEFvztoIOsFY9uB+3
iiVC083t/4y4qmlwbUuHfI7Oh6RNQTbYhCWDvD5XzW7wDONYrkYwrwvDy3suV8jE
vjnnufK4suEpE96dlI7O+ivudqVBLnvzVIqhJwTwsNUgIBO8ZKGgJDNSiRn00eSh
4+ooS3EHExW6xxeUYwS5t4WKHS463eABOs6EJiF7WnuX1hhNHdLS/kik7qtEZ2uU
yTHHKTklDHR3uToj6bCnaQnTVQVlN7Yde1ba8WqbzzSnFz+ir1RMElXkp7aCASnY
/V1bEPRnZtIaT8JRBAK2FDjnsrDFtTmuF+uU1FZxT1upoxOie3pT4d9hCJmpbhxu
z4UAXJ/DSI2V8cqR6GW4tEfXOJ7ZX8QSqakuAdlIlo+3EJ9xWwvhNh+EHdSQn2W7
vp8abxN8DuAD2nUjGjNOur1s53w16SH0w06pF5a+LBOkbGuBHsPYcNS6weu4kWWb
NdoT52omHiDe4zDAn5HZYvpfriRUD87SMPt5ipYv/5Lh9mYDO1qPjNAB6OX4Hir5
QhZwkVBzxbzdeoXpjSwa9xtLOW0VoCtknDEbfD7Eyd6/TAuzcHPaYK1PJlmpBNlq
0Eiz9LLeO2WRY0Z5WohWrpaRm/rjo0RbFKQPsgqw3RNTp4i93yvCcpb8bVMnjBIw
VScIBfb0XDQ/niIeclrN
=CrjN
-----END PGP SIGNATURE-----
Merge tag 'iommu-fixes-v4.7-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu
Pull IOMMU fixes from Joerg Roedel:
"Three patches queued up:
- Fix for ARM-SMMU to add a missing iommu-ops callback which is
required by common iommu code
- Fix for the rockchip iommu where the wrong MMUs got the commands
- A regression fix for the Intel VT-d driver. The regression only
showed up on X58 chipsets with more than one iommu. These chipsets
seem to require that QI is enabled on all IOMMUs before it can be
used"
* tag 'iommu-fixes-v4.7-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
iommu/vt-d: Enable QI on all IOMMUs before setting root entry
iommu/rockchip: Fix zap cache during device attach
iommu/arm-smmu: Wire up map_sg for arm-smmu-v3
Older btrfs-progs/mkfs.btrfs sets 4096 as the stripesize. Hence
restricting stripesize to be equal to sectorsize would cause super block
validation to return an error on architectures where PAGE_SIZE is not
equal to 4096.
Hence as a workaround, this commit allows stripesize to be set to 4096
bytes.
Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Introduced in 2c1984f244 ("btrfs: build fixup for
qgroup_account_snapshot") as temporary bisectability build fixup.
Signed-off-by: David Sterba <dsterba@suse.com>
This fixes a problem introduced in commit 2f3165ecf1
"btrfs: don't force mounts to wait for cleaner_kthread to delete one or more subvolumes".
open_ctree eventually calls btrfs_replay_log which in turn calls
btrfs_commit_super which tries to lock the cleaner_mutex, causing a
recursive mutex deadlock during mount.
Instead of playing whack-a-mole trying to keep up with all the
functions that may want to lock cleaner_mutex, put all the cleaner_mutex
lockers back where they were, and attack the problem more directly:
keep cleaner_kthread asleep until the filesystem is mounted.
When filesystems are mounted read-only and later remounted read-write,
open_ctree did not set fs_info->open and neither does anything else.
Set this flag in btrfs_remount so that neither btrfs_delete_unused_bgs
nor cleaner_kthread get confused by the common case of "/" filesystem
read-only mount followed by read-write remount.
Signed-off-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
This is just a screwup for developers, so change it to an ASSERT() so developers
notice when things go wrong and deal with the error appropriately if ASSERT()
isn't enabled. Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
Reviewed-by: Mark Fasheh <mfasheh@suse.de>
Signed-off-by: David Sterba <dsterba@suse.com>
The test for !trans->blocks_used in btrfs_abort_transaction is
insufficient to determine whether it's safe to drop the transaction
handle on the floor. btrfs_cow_block, informed by should_cow_block,
can return blocks that have already been CoW'd in the current
transaction. trans->blocks_used is only incremented for new block
allocations. If an operation overlaps the blocks in the current
transaction entirely and must abort the transaction, we'll happily
let it clean up the trans handle even though it may have modified
the blocks and will commit an incomplete operation.
In the long-term, I'd like to do closer tracking of when the fs
is actually modified so we can still recover as gracefully as possible,
but that approach will need some discussion. In the short term,
since this is the only code using trans->blocks_used, let's just
switch it to a bool indicating whether any blocks were used and set
it when should_cow_block returns false.
Cc: stable@vger.kernel.org # 3.4+
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Thanks to fuzz testing, we can pass an invalid bytenr to extent buffer
via alloc_extent_buffer(). An unaligned eb can have more pages than it
should have, which ends up extent buffer's leak or some corrupted content
in extent buffer.
This adds a warning to let us quickly know what was happening.
Now that alloc_extent_buffer() no more returns NULL, this changes its
caller and callers of its caller to match with the new error
handling.
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Component mirror_num of struct btrfsic_block is defined
as unsigned int. Use %u as format specifier.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Fix the signed issue in mv_write_cached_reg() where the laddr
is assigned from a (long)addr instead of (unsigned long)addr.
Fixes the following warnings:
drivers/ata/sata_mv.c:989:26: warning: cast removes address space of expression
drivers/ata/sata_mv.c:989:26: warning: cast removes address space of expression
drivers/ata/sata_mv.c:989:26: warning: cast removes address space of expression
drivers/ata/sata_mv.c:989:26: warning: cast removes address space of expression
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Tejun Heo <tj@kernel.org>
Most functions that take a GPIO descriptor in need to check the
descriptor for IS_ERR(). We do this mostly in the VALIDATE_DESC()
macro except for the gpiod_to_irq() function which needs special
handling.
Cc: stable@vger.kernel.org
Reported-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
commit 54d77198fd
("gpio: bail out silently on NULL descriptors")
doesn't work for gpiod_to_irq(): drivers assume that NULL
descriptors will give negative IRQ numbers in return.
It has been pointed out that returning 0 is NO_IRQ and that
drivers should be amended to treat this as an error, but that
is for the longer term: now let us repair the semantics.
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Reported-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The sysfs file for the libata error handling has multiple issues
in the way it prints time stamps:
* it prints a 9-digit nanosecond value using a %06lu format string,
which drops some leading zeroes
* it converts a 64-bit jiffes value to a timespec using
jiffies_to_timespec(), which takes a 'long' argument, so the
result is wrong after a jiffies overflow (49 days).
* we try to avoid using timespec because that generally overflows
in 2038, although this particular usage is ok.
This replaces the jiffies_to_timespec call with an open-coded
implementation that gets it right.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Tejun Heo <tj@kernel.org>
Make the sor1 and sor1_src clocks available on Tegra210. They will be
used by the display driver to support HDMI and DP.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The sor1 clock on Tegra210 is structured in the following way:
+-------+
| pllp |---+
+-------+ | +--------------+ +-----------+
+----| | | sor_safe |
+-------+ | | +-----------+
| plld |--------| | |
+-------+ | | +-----------+
| sor1_src |-------| |
+-------+ | | +-----------+
| plld2 |--------| | |
+-------+ | | |
+----| | |
+-------+ | +--------------+ |
| clkm |---+ +-----------+
+-------+ +--------------+ | |
| sor1_brick |-------| sor1 |
+--------------+ | |
+-----------+
This is impractical to represent in a clock tree, though, because there
is no name for the mux that has sor_safe and sor1_src as parents. It is
also much more cumbersome to deal with the additional mux because users
of these clocks (the display driver) would have to juggle with an extra
mux for no real reason.
To simply things, the above is squashed into two muxes instead, so that
it looks like this:
+-------+
| pllp |---+
+-------+ | +--------------+ +-----------+
+----| | | sor_safe |
+-------+ | | +-----------+
| plld |--------| | |
+-------+ | | +-----------+
| sor1_src |-------| sor1 |
+-------+ | | +-----------+
| plld2 |--------| | | |
+-------+ | | | |
+----| | | |
+-------+ | +--------------+ | |
| clkm |---+ | |
+-------+ +--------------+ | |
| sor1_brick |-----------+---+
+--------------+
This still very accurately represents the hardware. Note that sor1 has
sor1_brick as input twice, that's because bit 1 in the mux selects the
sor1_brick irrespective of bit 0.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Enabling spread spectrum on pll_d2 can lead to issues with display
modes. HDMI monitors, for example, would report "Signal Error" and
some modes driven over DisplayPort would generate fuzzy horizontal
bands.
Signed-off-by: Thierry Reding <treding@nvidia.com>
For readability and to allow for structure randomisation, replace the
in order struct initialisation style with explicit field style.
The Coccinelle semantic patch used to make this change is as follows:
@decl@
identifier i1,fld;
type T;
field list[n] fs;
@@
struct i1 {
fs
T fld;
...};
@@
identifier decl.i1,i2,decl.fld;
expression e;
position bad.p, bad.fix;
@@
struct i1 i2@p = { ...,
+ .fld = e
- e@fix
,...};
Signed-off-by: Amitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
To allow for structure randomisation, replace the in order struct
initialisation style with explicit field style.
The Coccinelle semantic patch used to make this change is as follows:
@decl@
identifier i1,fld;
type T;
field list[n] fs;
@@
struct i1 {
fs
T fld;
...};
@@
identifier decl.i1,i2,decl.fld;
expression e;
position bad.p, bad.fix;
@@
struct i1 i2@p = { ...,
+ .fld = e
- e@fix
,...};
Signed-off-by: Amitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
drm_plane_helper_check_update() needs to account for the plane rotation
for correct clipping/scaling calculations. Do so.
There was an earlier attempt [1] to add this into
intel_check_primary_plane() but I requested that it'd be put into the
helper instead. An updated patch never materialized AFAICS, so I went
ahead and cooked one up myself.
v2: Deal with new drm_plane_helper_check_update() callers
[1] https://patchwork.freedesktop.org/patch/65177/
Cc: Nabendu Maiti <nabendu.bikash.maiti@intel.com>
Cc: Noralf Trønnes <noralf@tronnes.org>
Cc: CK Hu <ck.hu@mediatek.com>
Cc: Mark Yao <mark.yao@rock-chips.com>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466172790-10025-1-git-send-email-ville.syrjala@linux.intel.com
We want to remove all time_t users from the kernel because of
y2038 compatibility. This particular instance does not even
use time_t to store a seconds value, so we can simply use
'unsigned int', which seems more fitting anywhere.
The same code is used in two OSS files.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch clubs the Renesas controller drivers in one rcar dir.
Signed-off-by: Ramesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
This patch adds support for the CAN FD controller found in Renesas R-Car
SoCs. The controller operates in CAN FD only mode by default.
CAN FD mode supports both Classical CAN & CAN FD frame formats. The
controller supports ISO 11898-1:2015 CAN FD format only.
This controller supports two channels and the driver can enable either
or both of the channels.
Driver uses Rx FIFOs (one per channel) for reception & Common FIFOs (one
per channel) for transmission. Rx filter rules are configured to the
minimum (one per channel) and it accepts Standard, Extended, Data &
Remote Frame combinations.
Note: There are few documentation errors in R-Car Gen3 Hardware User
Manual v0.5E with respect to CAN FD controller. They are listed below:
1. CAN FD interrupt numbers 29 & 30 are listed as per channel
interrupts. However, they are common to both channels (i.e.) they are
global and channel interrupts respectively.
2. CANFD clock is derived from PLL1. This is not documented.
3. CANFD clock is further divided by (1/2) within the CAN FD controller.
This is not documented.
4. The minimum value of NTSEG1 in RSCFDnCFDCmNCFG register is 2 Tq. It
is specified 4 Tq in the manual.
5. The maximum number of message RAM area the controller can use is 3584
bytes. It is specified 10752 bytes in the manual.
Signed-off-by: Ramesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The programming API of the CAN_BCM depends on struct can_frame which is
given as array directly behind the bcm_msg_head structure. To follow this
schema for the CAN FD frames a new flag 'CAN_FD_FRAME' in the bcm_msg_head
flags indicates that the concatenated CAN frame structures behind the
bcm_msg_head are defined as struct canfd_frame.
This patch adds the support to handle CAN and CAN FD frames on a per BCM-op
base. Main changes:
- generally use struct canfd_frames instead if struct can_frames
- use canfd_frame.flags instead of can_frame.can_dlc for private BCM flags
- make all CAN frame sizes depending on the new CAN_FD_FRAME flags
- separate between CAN and CAN FD when sending/receiving frames
Due to the dependence of the CAN_FD_FRAME flag the former binary interface
for classic CAN frames remains stable.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
can_frame is the name of the struct can_frame which is not meant in
the corrected comments.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
This patch Implements the ethtool set_phys_id callback to ease the
locating of specific physical devices. Currently only supported on
candleLight interfaces.
Signed-off-by: Hubert Denkmair <hubert@denkmair.de>
Signed-off-by: Maximilian Schneider <max@schneidersoft.net>
[mkl: split codingstyle change sinto separate patch]
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
This patch converts "1 << n" by BIT(n) and fixes the indention. No
functional change.
Signed-off-by: Hubert Denkmair <hubert@denkmair.de>
Signed-off-by: Maximilian Schneider <max@schneidersoft.net>
[mkl: split codingstyle changes into separate patch]
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
This driver does not do anything special in module init/exit. This patch
eliminates the module init/exit boilerplate code by utilizing the
module_isa_driver macro.
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Use CAN_MTU macro instead of sizeof(struct can_frame) just like the
other drivers do.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
This patch optimizes the calculation of the sample point. To understand what it
does have a look at the original implementation.
If there is a combination of timing parameters where both the bitrate and
sample point error are 0 the current implementation will find it.
However if the reference clock doesn't allow an optimal bitrate (this means the
bitrate error is always != 0) there might be several timing parameter
combinations having the same bitrate error. The original implementation will
allways choose the one with the highest brp. The actual sample point error
isn't taken into account.
This patch changes the algorithm to minimize the sample point error, too. Now a
brp/tseg combination is accepted as better if one of these condition are
fulfilled:
1) the bit rate error must be smaller, or
2) the bit rate error must be equal and
the sample point error must be equal or smaller
If a smaller bit rate error is found the sample point error is reset. This
ensures that we first optimize for small bit rate error and then for small
sample point errors.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
When building can subsystem with CONFIG_PROC_FS=n I detected some unused
variables warning by using proc functions. In CAN the proc handling is
nicely placed in one object file. This patch adds simple add a
dependency on CONFIG_PROC_FS for CAN's proc.o file and corresponding
static inline no-op functions.
Signed-off-by: Alexander Aring <aar@pengutronix.de>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
[mkl: provide static inline noops instead of using #ifdefs]
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Submitters of device tree binding documentation may forget to CC
the subsystem maintainer if this is missing.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Wolfgang Grandegger <wg@grandegger.com>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: linux-can@vger.kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
In gfs2_init_inode_once, initialize inode->i_iopen_gh.gh_gl to NULL:
otherwise, when gfs2_inode_lookup fails, the iopen glock holder can
remain unset and iget_failed can end up accessing random memory.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
We intended to test "usb2->phy" here instead of "dev".
Fixes: d3feb40673 ('phy: bcm-ns-usb2: new driver for USB 2.0 PHY on Northstar')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
The interrupt 0 is not a valid interrupt number. In the event where the
retrieval of the vbus-det gpio would return null, the gpiod_to_irq
callback would return 0, while the current code makes the assumption
that it is a valid interrupt, and would go on calling request_irq.
Obviously, this would fail, preventing the driver from probing properly,
while the vbus and id gpios are optional.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
