Synchronizes hotplug remove with the freeing of the port.
This ensures we have freed all the memory associated with
this port and are not leaking memory.
Signed-off-by: Brian King <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
(cherry picked from commit 28d49f8cbe9c7966f91ee1b5ec2f997f6e55bf9f)
Signed-off-by: Frank Heimes <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Cengiz Can <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
When hotplug removing an hvcs device, we need to ensure the
hangup processing is done prior to exiting the remove function,
so use tty_vhangup to do the hangup processing directly
rather than using tty_hangup which simply schedules the hangup
work for later execution.
Signed-off-by: Brian King <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
(cherry picked from commit d432228bc7b1b3f0ed06510278ff5a77b3749fe6)
Signed-off-by: Frank Heimes <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Cengiz Can <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
Rather than manually creating attributes for the hvcs driver,
let the driver core do this for us. This also fixes some hotplug
remove issues and ensures that cleanup of these attributes
is done in the right order.
Signed-off-by: Brian King <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
(cherry picked from commit 503a90dd619d52dcac2cc68bd742aa914c7cd47a)
Signed-off-by: Frank Heimes <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Cengiz Can <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
Use the dev_groups functionality to manage the attribute groups
for hvcs devices. This simplifies the code and also eliminates
errors coming from kernfs when attempting to remove a console
device that is in use.
Signed-off-by: Brian King <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
(cherry picked from commit 760aa5e81f33e0da82512c4288489739a6d1c556)
Signed-off-by: Frank Heimes <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Cengiz Can <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
The hvcs driver only ever gets two references to the port. One
at initialization time, and one at install time. Remove the code
that was trying to do multiple port puts for each open, which
would result in more puts than gets.
Signed-off-by: Brian King <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
(cherry picked from commit 6a9a733edd46732e906d976dc21a42dd361e53cc)
Signed-off-by: Frank Heimes <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Cengiz Can <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
02c0744...
by
Tyrel Datwyler <email address hidden>
powerpc/pseries: Fix of_read_drc_info_cell() to point at next record
The expectation is that when calling of_read_drc_info_cell()
repeatedly to parse multiple drc-info records that the in/out curval
parameter points at the start of the next record on return. However,
the current behavior has curval still pointing at the final value of
the record just parsed. The result of which is that if the
ibm,drc-info property contains multiple properties the parsed value
of the drc_type for any record after the first has the power_domain
value of the previous record appended to the type string.
eg: observed the following 0xffffffff prepended to PHB
In practice PHBs are the only type of connector in the ibm,drc-info
property that has multiple records. So, it breaks PHB hotplug, but by
chance not PCI, CPU, slot, or memory because they happen to only ever
be a single record.
Fix by incrementing curval past the power_domain value to point at
drc_type string of next record.
The ibm,drc-info property is an array property that contains drc-info
entries such that each entry is made up of 2 string encoded elements
followed by 5 int encoded elements. The of_read_drc_info_cell()
helper contains comments that correctly name the expected elements
and their encoding. However, the usage of of_prop_next_string() and
of_prop_next_u32() introduced a subtle skippage of the first u32.
This is a result of of_prop_next_string() returning a pointer to the
next property value which is not a string, but actually a (__be32 *).
As, a result the following call to of_prop_next_u32() passes over the
current int encoded value and actually stores the next one wrongly.
Simply endian swap the current value in place after reading the first
two string values. The remaining int encoded values can then be read
correctly using of_prop_next_u32().
Previous commit "UBUNTU: [Packaging] Remove in-tree abi checks" removed
module-check, abi-check, retpoline-check prerequisites for checks-<flavour>
target. All these were dependent on the install-<flavour> rule.
By removing these checks, install rule is now forgotten.
This caused issues during udeps build step because modules are nowhere
to be found and depmod failed:
"
...
depmod: ERROR: could not open directory /build/focal/debian/d-i-amd64/lib/modules/5.4.0-173-generic: No such file or directory
depmod: FATAL: could not search modules: No such file or directory
make[1]: *** [debian/rules.d/5-udebs.mk:16: do-binary-udebs] Error 1
make: *** [debian/rules.d/5-udebs.mk:4: binary-udebs] Error 2
"
Note: This should be a temporary fix.
In newer versions > focal, this is not required because install
is a prerequisite for the build rule (lp#1930713). This will be
considered to be backported to focal, bionic and xenial after a thorough
investigation.
