Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 大约 4 年

通知 14
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 16 6月, 2015 3 次提交
    • S
      rocker: revert back to support for nowait processes · 179f9a25
      由 Scott Feldman 提交于 
      One of the items removed from the rocker driver in the Spring Cleanup patch
series was the ability to mark processing in the driver as "no wait" for
those contexts where we cannot sleep.  Turns out, we have "no wait"
contexts where we want to program the device.  So re-add the
ROCKER_OP_FLAG_NOWAIT flag to mark such processes, and propagate flags to
mem allocator and to the device cmd executor.  With NOWAIT, mem allocs are
GFP_ATOMIC and device cmds are queued to the device, but the driver will
not wait (sleep) for the response back from the device.

My bad for removing NOWAIT support in the first place; I thought we could
swing non-sleep contexts to process context using a work queue, for
example, but there is push-back to keep processing in original context.
Signed-off-by: NScott Feldman <sfeldma@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      179f9a25
    • S
      rocker: fix neigh tbl index increment race · 4d81db41
      由 Scott Feldman 提交于 
      rocker->neigh_tbl_next_index is used to generate unique indices for neigh
entries programmed into the device.  The way new indices were generated was
racy with the new prepare-commit transaction model.  A simple fix here
removes the race.  The race was with two processes getting the same index,
one process using prepare-commit, the other not:

Proc A					Proc B

PREPARE phase
get neigh_tbl_next_index

					NONE phase
					get neigh_tbl_next_index
					neigh_tbl_next_index++

COMMIT phase
neigh_tbl_next_index++

Both A and B got the same index.  The fix is to store and increment
neigh_tbl_next_index in the PREPARE (or NONE) phase and use value in COMMIT
phase:

Proc A					Proc B

PREPARE phase
get neigh_tbl_next_index
neigh_tbl_next_index++

					NONE phase
					get neigh_tbl_next_index
					neigh_tbl_next_index++

COMMIT phase
// use value stashed in PREPARE phase
Reported-by: NSimon Horman <simon.horman@netronome.com>
Signed-off-by: NScott Feldman <sfeldma@gmail.com>
Reviewed-by: NSimon Horman <simon.horman@netronome.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4d81db41
    • S
      rocker: gaurd against NULL rocker_port when removing ports · a0720310
      由 Scott Feldman 提交于 
      The ports array is filled in as ports are probed, but if probing doesn't
finish, we need to stop only those ports that where probed successfully.
Check the ports array for NULL to skip un-probed ports when stopping.
Signed-off-by: NScott Feldman <sfeldma@gmail.com>
Acked-by: NJiri Pirko <jiri@resnulli.us>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a0720310
  3. 13 6月, 2015 1 次提交
    • R
      Fix Cavium Liquidio build related errors and warnings · 5b173cf9
      由 Raghu Vatsavayi 提交于 
      1) Fixed following sparse warnings:
    lio_main.c:213:6: warning: symbol 'octeon_droq_bh' was not
    declared. Should it be static?
    lio_main.c:233:5: warning: symbol 'lio_wait_for_oq_pkts' was
    not declared. Should it be static?
    lio_main.c:3083:5: warning: symbol 'lio_nic_info' was not
    declared. Should it be static?
    lio_main.c:2618:16: warning: cast from restricted __be16
    octeon_device.c:466:6: warning: symbol 'oct_set_config_info'
    was not declared. Should it be static?
    octeon_device.c:573:25: warning: cast to restricted __be32
    octeon_device.c:582:29: warning: cast to restricted __be32
    octeon_device.c:584:39: warning: cast to restricted __be32
    octeon_device.c:594:13: warning: cast to restricted __be32
    octeon_device.c:596:25: warning: cast to restricted __be32
    octeon_device.c:613:25: warning: cast to restricted __be32
    octeon_device.c:614:29: warning: cast to restricted __be64
    octeon_device.c:615:29: warning: cast to restricted __be32
    octeon_device.c:619:37: warning: cast to restricted __be32
    octeon_device.c:623:33: warning: cast to restricted __be32
    cn66xx_device.c:540:6: warning: symbol
    'lio_cn6xxx_get_pcie_qlmport' was not declared. Should it be s
    octeon_mem_ops.c:181:16: warning: cast to restricted __be64
    octeon_mem_ops.c:190:16: warning: cast to restricted __be32
    octeon_mem_ops.c:196:17: warning: incorrect type in initializer
2) Fix build errors corresponding to vmalloc on linux-next 4.1.
3) Liquidio now supports 64 bit only, modified Kconfig accordingly.
4) Fix some code alignment issues based on kernel build warnings.
Signed-off-by: NDerek Chickles <derek.chickles@caviumnetworks.com>
Signed-off-by: NSatanand Burla <satananda.burla@caviumnetworks.com>
Signed-off-by: NFelix Manlunas <felix.manlunas@caviumnetworks.com>
Signed-off-by: NRaghu Vatsavayi <raghu.vatsavayi@caviumnetworks.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5b173cf9
  5. 12 6月, 2015 33 次提交
  7. 11 6月, 2015 3 次提交
    • G
      net/ps3_gelic: Fix build error with DEBUG · 7161d18f
      由 Geoff Levand 提交于 
      When the DEBUG preprocessor macro is defined the ps3_gelic_net driver build
fails due to an undeclared routine gelic_descr_get_status().  This problem
was introduced during the code cleanup of commit
6b0c21ce (net: Fix p3_gelic_net sparse warnings),
which re-arranged the ordering of some of the gelic routines.

This change just moves the gelic_descr_get_status() routine up in the
ps3_gelic_net.c source file. There is no functional change.

Fixes build errors like these:

  drivers/net/ethernet/toshiba/ps3_gelic_net.c: error: implicit declaration of function gelic_descr_get_status
Signed-off-by: NGeoff Levand <geoff@infradead.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7161d18f
    • F
      net: phy: mdio-bcm-unimac: handle broken turn-around for specific PHYs · 1a3f4e83
      由 Florian Fainelli 提交于 
      Some Ethernet PHYs/switches such as Broadcom's BCM53125 have a hardware bug
which makes them not release the MDIO line during turn-around time.  This gets
flagged by the UniMAC MDIO controller as a read failure, and we fail the read
transaction.

Check the MDIO bus phy_ignore_ta_mask bitmask for the PHY we are reading
from and if it is listed in this bitmask, ignore the read failure and
proceed with returning the data we read out of the controller.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1a3f4e83
    • F
      net: bcmgenet: handle broken turn-around for specific PHYs · 9d3366e9
      由 Florian Fainelli 提交于 
      Some Ethernet PHYs/switches such as Broadcom's BCM53125 have a hardware
bug which makes them not release the MDIO line during turn-around time.
This gets flagged by the GENET MDIO controller as a read failure, and we
fail the read transaction.

Check the MDIO bus phy_ignore_ta_mask bitmask for the PHY we are reading
from and if it is listed in this bitmask, ignore the read failure and
proceed with returning the data we read out of the controller.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9d3366e9